Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73960 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34798 invoked from network); 6 May 2014 09:41:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 May 2014 09:41:21 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:57406] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FD/05-04569-E3EA8635 for ; Tue, 06 May 2014 05:41:19 -0400 Received: by klapt.com (Postfix, from userid 33) id 82BDF23D6106; Tue, 6 May 2014 11:41:14 +0200 (CEST) Received: from 188.110.63.152 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Tue, 6 May 2014 11:41:14 +0200 Message-ID: <830520339a3551c5df174b8a969875f1.squirrel@webmail.klapt.com> In-Reply-To: References: Date: Tue, 6 May 2014 11:41:14 +0200 To: "Dmitry Stogov" Cc: "Anatol Belski" , "Pierre Joye" , "PHP Internals" 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] phpng: Refactored PHP Engine with Big Performance Improvement From: anatol.php@belski.net ("Anatol Belski") On Tue, May 6, 2014 10:34, Dmitry Stogov wrote: > On Tue, May 6, 2014 at 12:21 PM, Anatol Belski > wrote: > > >> Hi Dmitry, >> >> >> On Tue, May 6, 2014 09:31, Dmitry Stogov wrote: >> >>> Hi Anatol, >>> >>> >>> >>> i agree that coordination from beginning would make some thing >>> easier, but I hardly believe we would able to do the PoC in short time >>> with endless discussions. >>> >>> Lets take what we have now. >>> I understand what you are not glad to do the same work once again. >>> I make take some part of this work, if we come to agreement. >>> >>> >> Yep, we have what we have now, so lets take it as the basis. I do not >> shy to take that effort as well, not a question at all. >> > > great! > > >> >>> >>> According to performance, I wouldn't believe to anything except >>> tests. and it's why I propose to start with the part that can't make >>> any harm. >>> >> Yeah, there is almost no diff if you look here >> >> >> http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20140411- >> masterr6c2f7bc-str_size_and_int64raa0c920.html (that's also linked from >> the RFC). Many scripting languages do support that like python and ruby >> and seem to have no harm. AFAIR Python even implements int64 on 32 bit >> platforms. So IMHO it really makes sense too keep both as then we have a >> balance between the functionality and performance, both will have a gain >> and both can get further improvement in the future. >> > > It's the reason why we are faster :) > > > support for both int32 and int64 is going to be a big overhead even on > 64-bit platforms. (I implemented and tested it about 8 years ago). > Each math opcdoe (ZEND_ADD, ZEND_MUL etc) are going to be complicated > finding the right operand types combination and overflow handling. > I wasn't suggesting to do that, especially not both 32 and 64 bit ints in the same build :). Just to ilustrate how the equilibrium could be kept. As you've seen, the discussion on the int64 RFC was started again. Lets see how we can proceed further after it. And i'll be testing the phpng branch the next days, too. Cheers Anatol