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

yes. We discussed that patch with Pierre for hours, and I always told that I afraid about memory consumption overhead. my tests showed it clearly phpng was started as closed project, because we didn't know if we'll able to succeed at all (it's not a first attempt) and we liked to move fast. Once, we got useful results we opened it. see https://wiki.php.net/phpng#performance_evaluation Thanks. Dmitry. On Wed, May 14, 2014 at 12:08 PM, Christian Stoller <stoller@leonex.de>wrote: > > Well put Nikita! > > > > Guys - we're in a bit of a ridiculous situation where the key low-level > > engine maintainers are saying this patch is unacceptable, yet it may pass > > due to the low level of overall interest and the lack of special rules to > > govern low-level changes like that (where with all due respect, I think > the > > main maintainers of the engine should get much stronger power). > > > > The patch the way it is now should be discarded; All the macro changes, > as > > well as any data structure change except for IS_LONG should be removed. > > > > Given that the current RFC doesn't thoroughly represent the performance > hit > > (in terms of memory footprint, as well as resulting performance hit - > > especially when using phpng), I recommend the following: > > > > * Add the relevant performance feedback from Dmitry to the RFC, as well > as > > his concerns as the chief performance guy php.net has > > * Provide an option for people to vote 'yes' for the IS_LONG size part > only > > > > If the authors of the RFC object, my request from everyone who has voting > > rights here is to vote 'no' and we can create a separate RFC for the > IS_LONG > > part only. Forcing this change against the explicit concerns of Dmitry > and > > Nikita, who worked their rear ends off to squeeze every bit of > performance > > in phpng (along with Xinchen, and now others joining in) - is, well, > > ridiculous IMHO. > > > > Zeev > > > >> 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 > > > > I am not a developer, but I think the approach of the phpng developers is > not fair. The 64 bit topic and its RFC has been worked on and discussed for > weeks or months and now theirs suddenly phpng and all the former work > should be thrown away? > > I have not followed the whole discussion about 64 bit/size_t, etc, so I > just want to ask if you, Nikita, Dmitry or Zeev have mentioned your view > and the issues before? > > Christian >