Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74331 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38436 invoked from network); 18 May 2014 08:26:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 May 2014 08:26:20 -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:58730] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 09/83-12623-AAE68735 for ; Sun, 18 May 2014 04:26:19 -0400 Received: (qmail 6013 invoked by uid 89); 18 May 2014 08:26:15 -0000 Received: by simscan 1.3.1 ppid: 5861, pid: 5987, t: 0.1677s 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; 18 May 2014 08:26:14 -0000 Message-ID: <53786F73.6050802@lsces.co.uk> Date: Sun, 18 May 2014 09:29:39 +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: <20140517133037.GA6153@analysisandsolutions.com> <2c358135f69515053b7b1fdac179027d@mail.gmail.com> In-Reply-To: <2c358135f69515053b7b1fdac179027d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [VOTE] [RFC] 2/3 vote needed From: lester@lsces.co.uk (Lester Caine) On 18/05/14 07:13, Zeev Suraski wrote: > I still argue that the RFC > process was never meant to be about implementation, it was so outside the > scope of the RFC process that I didn’t even think about this possibility > when I helped drafted it. There are three types of change to the code base that are of interest here. I know that many consider the 'distributed' version as core. but in reality many elements of that can be considered as extensions, and as such people can still work with a much more compact distribution. So as long as things like 'annotations' can be configured so that core code does NOT require it to work, then discussions on that can be left to those who have an interest. Until now unicode has been considered on that basis and mbstring provides the 'namespace'. Moving multibyte strings into mainstream code functionality has been happening but in a piecemeal manor which like the 32/64bit discussion impacts a core set of code, but few people actually understand the ramifications of 'little changes' for which we rely on a core elite to advise where hidden mines may be activated? I am an electronics engineer by original training, and am still more at home with low level coding on processors that one can actually understand the operation of. The x86 family of processors moved outside that frame a long time ago, and I would contest that few 'software engineers' actually understand what they are programming on, so making adjustments to how the core code interacts with the hardware running it is something of a black art? It may have been relatively easy when there was only AMD and Intel, but adding Via and other embedded x86 environments such as Atom brings a new set of mines. Throw into the mix the vast range of similarly powered ARM based processors which do not run x86 and we have a whole minefield? Where do the changes being made in phpng fit into this tree? They are attempting to reduce memory footprint so affect all the core API by changing how structures are stored, and that may well be a good base to build off, but on 64bit processors is it actually better to leave gaps to correctly align 'words' that are 64bit based on these processors but where packing two 32bit elements results in extra time to break these apart? Certainly on the 64bit ARM processors correctly splitting elements that are best processed in different registers can make a difference. The main memory interface may be a bottleneck, but the growing size of first line caches can offset that where large chunks of code may be resident for a long period of time. That the compilers come into this discussion is even more relevant since different compilers will produce a different set of alignments? Handling a simple 10 byte string could produce vastly different results depending on it's alignment, and with 32 bit processors it was originally more efficient to align to a 32bit boundary and pad to 12 bytes, so do these simple rules map to the 64bit case? Reducing memory footprint may give gains in one area, but at a cost in others? Alternatively would reducing the large number of stings used for names of every type be more efficient actually as 16bit string length? 10 years ago the answers were fairly simple, but today does anybody actually know the answer? Getting the core of a PHPNext right will be important and while I understand why phpng has only recently been advertised given the amount of work needed to get even it's limited application working, what is needed is a much wider assessment that everybody can at least trial! -- 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