Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71556 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55192 invoked from network); 25 Jan 2014 10:47:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jan 2014 10:47:13 -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:51224] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 92/60-53277-F2693E25 for ; Sat, 25 Jan 2014 05:47:13 -0500 Received: by klapt.com (Postfix, from userid 33) id 318F023D60EC; Sat, 25 Jan 2014 11:47:08 +0100 (CET) Received: from 94.216.38.193 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Sat, 25 Jan 2014 11:47:08 +0100 Message-ID: In-Reply-To: References: <52E0F55F.4040802@lsces.co.uk> <52E16AC2.8070400@ajf.me> Date: Sat, 25 Jan 2014 11:47:08 +0100 To: "Dmitry Stogov" Cc: "Pierre Joye" , "Andrea Faulds" , "Derick Rethans" , "PHP Internals" 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 Dmitry, 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. Regards Anatol