Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71560 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72652 invoked from network); 25 Jan 2014 14:54:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jan 2014 14:54:52 -0000 Authentication-Results: pb1.pair.com header.from=ab@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ab@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender) X-PHP-List-Original-Sender: ab@php.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:54765] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E7/12-53277-A30D3E25 for ; Sat, 25 Jan 2014 09:54:52 -0500 Received: by klapt.com (Postfix, from userid 33) id 059FC23D60EC; Sat, 25 Jan 2014 15:54:47 +0100 (CET) Received: from 94.216.38.193 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Sat, 25 Jan 2014 15:54:47 +0100 Message-ID: <8022d6fe69d5ad24efc952667baac460.squirrel@webmail.klapt.com> In-Reply-To: <52E3AED9.5080805@lsces.co.uk> References: <52E0F55F.4040802@lsces.co.uk> <52E16AC2.8070400@ajf.me> <52E3AED9.5080805@lsces.co.uk> Date: Sat, 25 Jan 2014 15:54:47 +0100 To: "Lester Caine" Cc: internals@lists.php.net Reply-To: "Anatol Belski" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length and integer From: ab@php.net ("Anatol Belski") Hi Lester, On Sat, January 25, 2014 13:32, Lester Caine wrote: > 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? this RFC has no plans to discriminate 32-bit platforms, but merely to improve the 64-bit ones. 32-bit platforms are nowadays mature, consistent and well supported, whereas 64-bit platforms have much more non exhausted potential and still luck on proper software ports at many places. Regards Anatol