Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73938
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 74.125.82.171 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU6VrgxCBGbNTpzQTK_TWf4VB4840dBmzraJc8YgORR7Dw@mail.gmail.com>
References: <CA+9eiLtKFMWn7AXyS3_fni1Dyerx3DUW7imZ08P9gLr_FY=TaA@mail.gmail.com>
	<CAEZPtU6Eh6pXOXyX_pVEm2bcsZtfoLwLND-HeCuk3xMuwpc4xQ@mail.gmail.com>
	<CA+9eiLvHLWuA81s-oQY4Q7qydFRgskYDUOL6tSctyoe5Aw1z4w@mail.gmail.com>
	<CAEZPtU6VtgtCBb9miiOUAOZVNGfEt5+BkBLsTO57Aiuvk6JFGg@mail.gmail.com>
	<CA+9eiLtojqZZ-5SQSvitNkwL=Knp7NxwKSth3dHYNsFZDcAeRA@mail.gmail.com>
	<CAEZPtU6VrgxCBGbNTpzQTK_TWf4VB4840dBmzraJc8YgORR7Dw@mail.gmail.com>
Date: Tue, 6 May 2014 09:56:57 +0400
Message-ID: <CA+9eiLtT_wzVsv+p=m7vwU72XsAOi6yTndsUak57nd-MDudFZw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04138e5f6e71b604f8b4ea83
Subject: Re: [PHP-DEV] phpng: Refactored PHP Engine with Big Performance Improvement
From: dmitry@zend.com (Dmitry Stogov)

--f46d04138e5f6e71b604f8b4ea83
Content-Type: text/plain; charset=UTF-8

int64 proposal is still in draft for very long time.
Do you provide support for all other unrelated proposals when you offer
your own?

Lets think how to integrate them. I propose doing it in two steps
(measuring the performance and memory consumption difference).
If the degradation is going to be invisible, I won't object.

Thanks. Dmitry.




On Tue, May 6, 2014 at 9:43 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> On Tue, May 6, 2014 at 7:27 AM, Dmitry Stogov <dmitry@zend.com> 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
>

--f46d04138e5f6e71b604f8b4ea83--