Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73943
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <c2ab2a26fe39d89c2a2b7c75362d1858.squirrel@webmail.klapt.com>
In-Reply-To:
 <CA+9eiLtojqZZ-5SQSvitNkwL=Knp7NxwKSth3dHYNsFZDcAeRA@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>
Date: Tue, 6 May 2014 09:20:31 +0200
To: "Dmitry Stogov" <dmitry@zend.com>
Cc: "Pierre Joye" <pierre.php@gmail.com>,
 "PHP Internals" <internals@lists.php.net>
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 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