Re: [VOTE] [RFC] 64 bit platform improvements for string length and integer

On Wed, May 14, 2014 at 6:44 AM, Pierre Joye <pierre.php@gmail.com> wrote: > hi Dmitry. > > On Wed, May 14, 2014 at 12:52 AM, Dmitry Stogov <dmitry@zend.com> wrote: > > Anatol, > > > > We discussed your patch in private and I showed you the big penalty it > > makes... > > We discussed how we could best cooperate to get phpng and this patch > together to ease everyone's work. > > > I really, don't see, what do you like to achieve initiating voting right > > after that. :( > > Moving forward as you rejected the whole idea for no good reason or > based on numbers that cannot be taken as valid as this stage. > > > Your zend_size_t related changes, in my opinion, makes little sense and > > actually makes more harm. I recompiled phpng with your patch on Linux > > x86_64 and got the following numbers: > > > > zend_string size increased from 24 to 32 bytes > > HashTable size increased from 56 to 72 bytes > > zend_op_array size increased from 248 to 264 bytes > > zend_class_entry size increased from 512 to 568 bytes > > size of each opcode sizeof(zend_op) from 48 to 56 bytes > > These numbers cannot be taken as valid or seriously at this stage. > Restructuring these structs will certainly reduce the delta. I did not > have the time to analyze phpng possible other improvements but I will > do it soon, and will also check with other people from the compiler > team if we can improve it a bit more as well. > Sorry, what did I miss here? Why cannot the phpng numbers be taken as "valid"? The very same issue also exists in our current implementation. In phpng the relative hit is just larger, because the structures are more optimized. I think you shouldn't dismiss Dmitry's point just like that. Having support for 64 bit integers on Windows and other LLP64 architectures - that's great. Making string lengths unsigned - that's great as well. But supporting strings larger than 4G or arrays with more than 4 billion elements - that does not seem very useful and unlike the other two changes, hurts memory usage. I wonder how many people would prefer having lower memory usage over having the ability to create arrays with 4 billion elements. Independently of that: In a lot of the previous discussion people have many, many, many times asked that this patch be implemented without all those macros renames and zpp changes. I still have a hard time seeing the benefit of doing that. The zpp changes also conflict with phpng, because S has a different meaning (and imho for no good reason - it could just as well stay at s). Nikita