Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71557 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64683 invoked from network); 25 Jan 2014 12:30:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jan 2014 12:30:15 -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:53229] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1A/D0-53277-65EA3E25 for ; Sat, 25 Jan 2014 07:30:15 -0500 Received: (qmail 2071 invoked by uid 89); 25 Jan 2014 12:30:10 -0000 Received: by simscan 1.3.1 ppid: 2061, pid: 2066, t: 0.0703s 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; 25 Jan 2014 12:30:10 -0000 Message-ID: <52E3AED9.5080805@lsces.co.uk> Date: Sat, 25 Jan 2014 12:32:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: internals@lists.php.net References: <52E0F55F.4040802@lsces.co.uk> <52E16AC2.8070400@ajf.me> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length and integer From: lester@lsces.co.uk (Lester Caine) Anatol Belski wrote: > On Fri, January 24, 2014 12:29, Dmitry Stogov wrote: >> >I would be glad t see any 64-bit performance related improvements. >> > >> >BTW: the performance degradation is expected. Each pointer is 64-bit >> >instead of 32-bit => more memory consumption => more CPU cache pressure => >> > more CPU cache misses. >> > >> >On the other hand x86-64 uses more CPU registers, MMX, SSE, passes >> >arguments in registers, so it's usually faster on small tasks that keep >> >working set in CPU caches. >> > > Wouldn't then the small parts improve the whole? Fixing the small cases > laying on the surface like implicit 32 vs 64 bit type conversions, better > struct packing and similar measures would already contribute to more > efficient processor and memory usage. That would probably turn many things > even more upside down though:) As yep, potentially 64 bit should be > faster, so it's worth a try to lean PHP towards. > > Especially as you welcome it, I would put the topic on my todo after > properly finishing this RFC. Besides potential improvement that's also an > exciting matter. Much of the 'improved performance' provided by later versions of windows is down to faster processors to hide the extra bloat created. They have adopted having a 32bit version and a 64bit version. Making PHP super efficient on 64bit processors would be useful, but it still misses the point of being able to fall back gracefully to run on 32bit machines? Or is now the time to introduce the same differentiation in all builds of PHP? It is built for the platform? The main problem here is that changing things to be more 64bit efficient could then make things even worse on 32bit? Yes we need to be modernising, but telling users to 'read the source code' to find out where functions are now returning 64 bit values rather than 32bit ones is not the right approach? -- 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