Re: [RFC] 64 bit improvements, open questions

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