Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73937 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78054 invoked from network); 6 May 2014 05:43:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 May 2014 05:43:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.49 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.192.49 mail-qg0-f49.google.com Received: from [209.85.192.49] ([209.85.192.49:45356] helo=mail-qg0-f49.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F4/8D-44049-E6678635 for ; Tue, 06 May 2014 01:43:11 -0400 Received: by mail-qg0-f49.google.com with SMTP id a108so2170113qge.8 for ; Mon, 05 May 2014 22:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PzfiGavGe5nSpQljlyjkbYkNA3Ci/5OjSx4nYzkAn6w=; b=aKPqEkU4Yi/xptF5eXHR/dwq3sxZVZBOhGv0FlNyj1E1VTWnky4aooMSMNAFzIYdmP bVHwu8Fq+7qtsDp1z5a7pDB6gkWHWwzQbVKfOFlLMif2G1GcH+7yskC1VIRtrd376Kiq +3G/3FMvyUkhcQmY5sVMgP3/5fyi/xSVZidvbbdS+rA2+dqbx3k08dHi17Id+91pcCuN mihAFlQXQ5aVMnhvy3fC0ova9wjvyit2ge7LPGURjpAo+5ac7X1yjSZzNKM7XusNHkbA 9onDl25DJyX/8idqHvDB7e81U2UXYHJUlbN78jsREk6cMhM6P2H9zW57PTITMVJMz3we 4Jyw== MIME-Version: 1.0 X-Received: by 10.140.98.233 with SMTP id o96mr47626077qge.86.1399354988558; Mon, 05 May 2014 22:43:08 -0700 (PDT) Received: by 10.140.47.231 with HTTP; Mon, 5 May 2014 22:43:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 May 2014 07:43:08 +0200 Message-ID: To: Dmitry Stogov Cc: PHP Internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] phpng: Refactored PHP Engine with Big Performance Improvement From: pierre.php@gmail.com (Pierre Joye) On Tue, May 6, 2014 at 7:27 AM, Dmitry Stogov wrote: > I really, don't see a lot of sense in using ZTS and didn't like to spend our > time. Well, it is not a taste matter and we all have to take care of issues on platforms/sapis we do not use daily. >> >> Also one thing is totally missing, and is also caused by something >> >> that becomes a common case, the 64bit support as it should be has been >> >> totally ignored. That makes Anatol work to keep the 64bit branch >> >> almost useless. My take on it is that we should either: >> >> >> >> >> >> - move your patch to this branch and then merge to master >> >> - merge the 64bit branche then this patch >> > >> > >> > I afraid both ways aren't going to be simple. >> >> Rght, but again, I really do not feel comfortable to ask Anatal or my >> team to redo all the work. This would be very bad. > > > I see your point. Please, look from mine. > Just compare the sizes of diffs between branches. > We won't be able to care about unstable development branches... It is stable as far as we can tell and has been working constantly since we proposed it. Tests results are public and very positive. Thing is that every individual here is not alone on working on php, care has to be taken. > We may help, with reimplementation of int64 patch, but actually we come to > ask help ourselves. > I hope we will found some compromise. It can't be a problem if our goals are > not opposite :) We have the same goals :) While performance is a lower priority to me than clean code and maintainability in the long run. But both performance and ease of maintainability can be achieved together. >> > Anyway, I think 64-bit integer support on Windows64 makes full sense and >> > it's possible to add it into "phpng" right now. >> >> Again, it is by far not only a windows change, even if Windows is the >> platform with the most visible change from a user point of view. > > > OK. Win64 is enough for this patch. I wouldn't care about others, because I > even don't know the names. Err, even Linux has a not so good 64bit implementation. We rely on single compiler behavior and 20 years old types described by many leading developers as hacks. PHP is one of the only OSS projects I know still relying on these types or using int for buffer size. I am not willing to tell you what you should care about but this is definitively an area that deserves more attention. >> > I'm not so sure about size_t string length. >> >> It is hardly imaginable to release php 6 with strings length still >> using integer. The memory consumption has been shown to be minimal >> during the discussions about the 64bit support. Or did I miss some >> important new information? > > > I wouldn't mix size_t string length with 64-bit support. These are two > independent changes. > int64 would make 64-bit PHP version behave more or less consistent with > minimal cost. There are part of the same changeset. They are even deeply related. > > size_t string length will increase memory consumption and memory traffic for > the cases that no one web application will use (2GB strings). > I'm trying to save (or even improve) memory consumption, because I know how > it may affect performance because of CPU cache misses. > > Lets apply the first part first. I have to disagree here, the patch contains both changes and will be proposed together. I do not see an appealing reason to split them for a minimal gain from a memory usage point of view. The importance and gains brought by these changes are too important. The "new" RFC and patch are ready, it will be proposed soonish. If accepted, let see what is the best way to make your patches work with it, we can help here with the moves anyway :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org