Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71408
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender)
Message-ID: <abd00eb2d35de79f648e8195f27b0776.squirrel@webmail.klapt.com>
In-Reply-To:
 <CAMUwpuSKDCS4g-Luy2QphBg0CFfGb=Dbpm0BuenRzYchAnrAWg@mail.gmail.com>
References: <d27df615bc27d701daceb5ee605f540f.squirrel@webmail.klapt.com>
    <CAMUwpuSKDCS4g-Luy2QphBg0CFfGb=Dbpm0BuenRzYchAnrAWg@mail.gmail.com>
Date: Wed, 22 Jan 2014 13:58:27 +0100
To: "Julien Pauli" <jpauli@php.net>
Cc: "PHP internals" <internals@lists.php.net>
Reply-To: "Anatol Belski" <ab@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] [RFC] 64 bit improvements, open questions
From: ab@php.net ("Anatol Belski")

Hi Julien,

On Wed, January 22, 2014 11:56, Julien Pauli wrote:
> On Wed, Jan 22, 2014 at 9:20 AM, Anatol Belski <ab@php.net> wrote:
>
>> Hi,
>>
>>
>> as the discussion phase for this RFC nears to the finish and the patch
>> itself is huge, I'd like to use the last chance to discuss the open
>> questions and concerns. Here are once more the links to the RFC (with
>> several updates) and the porting guide
>>
>> https://wiki.php.net/rfc/size_t_and_int64
>> http://git.php.net/?p=php-src.git;a=blob;f=compat/PECL_PORTING;hb=refs/h
>> eads/str_size_and_int64
>>
>> The big open question from the previous discussion is how to handle
>> changed ZPP formats. The way I've suggested in the porting doc is using
>> ternary operator like (COMP ? "l" : "i"). Another way were to put the
>> old ZPP formats "lLsp" back and make them redundant to the new ones
>> "iISP".
>> Both ways have their pro and contra, the second variant isn't done, but
>> can be done quickly.
>
> That's a good question.
> Having to check for a macro and adapt parameters at every zpp() call
> would be painful, however we already do such things in other scenarios to
> take care of compatibility, so ... I would however rename the macro to
> something more meaningfull, same for PHP_NEED_COMPAT which should be named
> something like PHP_NEED_STRSIZE_COMPAT
>
Lets rename that. As the header (coupled with the replace tool) might work
out of the box, one could even make a wrapper to use like
ZEND_ZPP_COMPAT("l", "i"). In complicated cases that header will need to
be customized.

>> Also one big question from the RFC which haven't been addressed is the
>> handling of the stale SAPIs. While porting it turned out, that more than
>>  50% of SAPIs reference no more actively supported web servers, some of
>>  them are even not available anymore, no packages in the current
>> distributions seem to exist, no chance to check if they even complaint
>> with PHP mainstream. The SAPIs ported so far - apache2handler, CGI,
>> CLI,
>> embed, FPM, phpdbg.
>
> I would suggest getting rid of those old SAPIs nobody use anymore.
> Late 90's SAPI that are not used/maintained anymore can die , IMO.
>
That's what I was tempted to express too :)

>
> I also have a memory usage question.
> Have we measured the impact of extending all 32 ints to 64 ? Memory
> usage should be higher, but how many higher ?
That's not tested, whereby it is expected to be some higher. One for zval,
as Pierre explained. Even for zval it might stay the same depending on
default/used field alignment (like on mashines with word size of 64 bit).
Two - for the places where datatypes in function signatures or stack
variables has to be adapted, like for string size. That's the matter of 4
bytes per item as well, whereby things on the stack don't really matter.
Lets see what snippets can be invented for such a test :)

> Then is all that compatible with OPCache ?
> I guess yes and see nothing which would be blocking, anyway better ask.
>
All the core extensions are ported so far, so opcache as well.

>
> Anyway I'm all OK to merge this to 5.6 (should the RFC be accepted),
> this is a great push in PHP crossplatform handling, thanks for the huge
> work done so far !
>
That's a great thing, and thanks for the constructive feedback :)

Regards

Anatol