Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74175 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76181 invoked from network); 14 May 2014 09:10:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 May 2014 09:10:33 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:57734] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 59/67-40033-70333735 for ; Wed, 14 May 2014 05:10:32 -0400 Received: (qmail 1345 invoked by uid 89); 14 May 2014 09:10:29 -0000 Received: by simscan 1.3.1 ppid: 1338, pid: 1342, t: 0.0763s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 14 May 2014 09:10:29 -0000 Message-ID: <537333BF.7070106@lsces.co.uk> Date: Wed, 14 May 2014 10:13:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: <4ED7146272E04A47B986ED49E771E347BBDA6AAA06@Ikarus.ameusgmbh.intern> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string length and integer From: lester@lsces.co.uk (Lester Caine) On 14/05/14 09:21, Dmitry Stogov wrote: > yes. We discussed that patch with Pierre for hours, and I always told that > I afraid about memory consumption overhead. > my tests showed it clearly > > phpng was started as closed project, because we didn't know if we'll able > to succeed at all (it's not a first attempt) and we liked to move fast. > Once, we got useful results we opened it. > seehttps://wiki.php.net/phpng#performance_evaluation Dmitry As all of my systems are based on Firebird, I can't currently test even if I did have the time. One area that I have problems with is the fact that 64 bit numbers are a key element of SEQUENCE/GENERATOR values which PHP does not support well and which I'd like to see fixed, but I can understand your concern over 64bit strings increasing memory consumption. This is why I think that lumping several 64bit related items together does not make sense? Looking at this from the hardware side, some 64bit processes will be faster on a 64bit machine, but also supporting 32bit builds simply adds to the overheads. I'd prefer to see better coverage of benchmarking since I don't think limited testing gives the whole picture? But I don't see 64/32 changes having a substantial effect. Do we need 64bit long strings - not generally - but the facility should be covered properly while still retaining 32bit operations? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk