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

From: Date: Wed, 14 May 2014 05:46:46 +0000
Subject: Re: [VOTE] [RFC] 64 bit platform improvements for string length and integer
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-74153@lists.php.net to get a copy of this message
On Wed, May 14, 2014 at 7:30 AM, Nikita Popov <nikita.ppv@gmail.com> wrote: > Sorry, what did I miss here? Why cannot the phpng numbers be taken as > "valid"? At this stage, this is a key part of this sentence. > 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. I do not and did not. I would love to see the same from the phpng side, but it failed, for no valid reason. > 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 Very large string or arrays are only side effects, it does not change the goals and benefits of these changes. > - 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. This is a biased argument, you know it, I know it. The key point is not about the new maximum size of an array or string but the long due clean and safe 64bit implementation, following well known good practice (can be seen in almost all other OSS projects out there) and standards. > 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). This can be adapted, this is a details. It is also why I have tried to get phpng and this patch along together and get both teams work together. Cooperation in this case will be benefit for php as a whole as more optimization can be achieve while keeping the safe&clean implementation. As of now, phpng has been worked on for the last months, totally privately. And even if it looks promising it is still not remotely ready to be actually proposed. However it does not prevent you to use it to stop other improvements, which have been worked on for months, publically, with continuous tests, status updates, etc. I am not sure what is happening here is good for PHP. Cheers, -- Pierre @pierrejoye | http://www.libgd.org

« previous php.internals (#74153) next »