Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73944
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 74.125.82.175 cause and error)
MIME-Version: 1.0
In-Reply-To: <c2ab2a26fe39d89c2a2b7c75362d1858.squirrel@webmail.klapt.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>
	<c2ab2a26fe39d89c2a2b7c75362d1858.squirrel@webmail.klapt.com>
Date: Tue, 6 May 2014 11:31:30 +0400
Message-ID: <CA+9eiLufd8q4nT4NA8=gq7EOJDsMmmVxDZaa71Z5_4TE7xpm8w@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: Pierre Joye <pierre.php@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2aca28d389204f8b63c56
Subject: Re: [PHP-DEV] phpng: Refactored PHP Engine with Big Performance Improvement
From: dmitry@zend.com (Dmitry Stogov)

--001a11c2aca28d389204f8b63c56
Content-Type: text/plain; charset=UTF-8

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.

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.

Thanks. Dmitry.




On Tue, May 6, 2014 at 11:20 AM, Anatol Belski <anatol.php@belski.net>wrote:

> On Tue, May 6, 2014 07:27, Dmitry Stogov wrote:
>
> >>> 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.
> >
> >
> >>> 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.
> >
> > 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.
> >
> just two cents about the size_t part.
>
> The possible memory increase on 64 bit is unproportional to the increase
> of the available memory on the 64 bit system itself. While it's less then
> 4bg on 32 bit systems, it's usually at least 8gb or more on a 64 bit
> system (otherwise there were no reasons to use a 64 bit machine IMHO). So
> from this POV it's almost uncritical. Furthermore, the big part of that
> will be going on the image size, not on the heap (on linux zval didn't
> increase).
>
> Regarding the possible performance issue you mentioned - yes, it can be as
> well, but not worse as it is. However as discussed before, the usage of
> the mem types like size_t and ptrdiff_t is mentioned by CPU manufacturers
> as a good thing to do as apart from cache it'll lead to more optimal
> memory and registers usage. The same is about the other cases like usage
> of right data types in the loops, security with the string lengths coming
> as 64 bit int from the user space, pointer casts to int instead of
> ptrdiff_t, etc. This topic was and is on the plate and was just defered to
> the time the int64 patch were accepted. One can see what exactly the
> bottle necks are using the tools from the CPU manufacturers like AMD and
> Intel. That is definitely an outstanding task which were far in advance
> now if the int64 patch were in 5.6 now.
>
> More on memory usage is that right now many memory structures can be
> optimized for better alignment which would decrease their allocated sizes.
> Of course that has to be revisited again in the new patches. But that
> could free an amount of memory.
>
> IMHO it's much more important to do a clean start now with both patches
> and drive them to the top. That's why we should have coordinated our works
> on that which would save our efforts on merging it and allow a better
> result from the start on.
>
> Best regards
>
> Anatol
>

--001a11c2aca28d389204f8b63c56--