# [VOTE] [RFC] 64 bit platform improvements for string length and integer - Thread: https://externals.io/message/74148 - Original archive: https://news-web.php.net/php.internals/74148 - Started by Anatol Belski on 2014-05-13T20:51:41+00:00 - Messages: 85 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/74148.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #74148 — Anatol Belski — 2014-05-13T20:51:41+00:00 URL: https://externals.io/message/74148#74148 Hi, as announced previously, the vote starts on May 13th and ends on May 20th. https://wiki.php.net/rfc/size_t_and_int64_next#vote The RFC is considered approved with 50%+1 acceptance. Happy voting :) Best regards Anatol --- ## #74149 — Dmitry Stogov — 2014-05-13T22:52:21+00:00 URL: https://externals.io/message/74148#74149 · In reply to: #74148 Anatol, We discussed your patch in private and I showed you the big penalty it makes... I really, don't see, what do you like to achieve initiating voting right after that. :( I've just take a quick look over your initial patch for phpng at https://gist.github.com/weltling/a941d8cf6c731640b51f Actually, I would support only one idea from your patch - make IS_LONG to be 64-bit on _WIN64. 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 Anyone may recompile phpng (with and without patch) and then get these number running $ gdb sapi/cli/php > p sizeof(zend_string) ... Can you imagine memory consumption difference on a large application? More memory usage => more CPU cache misses => worse performance. and what are the advantages? strings and class names > 2GB? For me it's too big payment for useless feature. -1 Thanks. Dmitry. On Wed, May 14, 2014 at 12:51 AM, Anatol Belski wrote: > Hi, > > as announced previously, the vote starts on May 13th and ends on May 20th. > > https://wiki.php.net/rfc/size_t_and_int64_next#vote > > The RFC is considered approved with 50%+1 acceptance. Happy voting :) > > Best regards > > Anatol --- ## #74150 — Pierre Joye — 2014-05-14T04:44:59+00:00 URL: https://externals.io/message/74148#74150 · In reply to: #74149 hi Dmitry. > 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. > I've just take a quick look over your initial patch for phpng at > https://gist.github.com/weltling/a941d8cf6c731640b51f > > Actually, I would support only one idea from your patch - make IS_LONG to > be 64-bit on _WIN64. Again. This patch is about clean, safe, standard implementation for 64bit plaforms and modern compilers, by far not only for windows (which has one more gain with this patch, portability). It brings a lot of guards, as well as safe and clean implementations. This is something we should have done a long time ago. PHP is only of the only OSS language I know still relying on old types and using integer for buffer length. This is a bad practice and a well known troubles source. To reduce it to only windows is hardly a good move. > 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. But rejecting a safe and clean 64bit support for a prototype, even promising, is wrong, in so many ways. See below. > Anyone may recompile phpng (with and without patch) and then get these > number running > $ gdb sapi/cli/php > > […] > ... > > Can you imagine memory consumption difference on a large application? > More memory usage => more CPU cache misses => worse performance. I can imagine a lot of things but at this point phpng is a very good prototype with promising results. There is a good base idea and a lot of changes in many places improving performance. However it is very far away from being ready, APIs are very inconsistent and painful to use (mix of zend_string and char* usage, remaing or removal which may not make sense or make the code way too complicated). > and what are the advantages? strings and class names > 2GB? > For me it's too big payment for useless feature. I do not think it is that useful for both of us to redo the discussions about this patch and its goal. It is a necessary step for 64bit support. It is also very hard to use a prototype, developed for months privately and still being in very early pre-alpha/testing phase as argument to reject these changes. However, as I told you, it would be way better to do both together, for everyone. But you reject the idea. We have to move forward to php-next and I do not think we can afford to wait months until phpng is remotely usable or stable (at least APIs wised). In any case, if the 64bit patch is accepted we will support you and other with phpng as we always do, even before its RFC or proposal, this is what I call cooperation and teamwork. Cheers. Pierre --- ## #74151 — Nikita Popov — 2014-05-14T05:30:48+00:00 URL: https://externals.io/message/74148#74151 · In reply to: #74150 > hi Dmitry. > > > > […] > > We discussed how we could best cooperate to get phpng and this patch > together to ease everyone's work. > > > […] > > 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. > > > […] > > 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 --- ## #74152 — Terry Ellison — 2014-05-14T05:44:44+00:00 URL: https://externals.io/message/74148#74152 · In reply to: #74151 > > 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 don't have a vote on the RFC but I still have to say +1 on this one. It makes sense to me to fix stuff that people might need in the next 5-10 years, but beyond that ??? IMO, Nikita has summarized the sensible threshold well. Regards Terry --- ## #74153 — Pierre Joye — 2014-05-14T05:46:46+00:00 URL: https://externals.io/message/74148#74153 · In reply to: #74151 > 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 --- ## #74154 — Dmitry Stogov — 2014-05-14T05:57:59+00:00 URL: https://externals.io/message/74148#74154 · In reply to: #74150 Pierre, you developed a patch that will negatively affect every PHP application, just to use "modern" types... it's completely not necessary step for 64-bit support. As I said, I can support only part of your patch related to IS_LONG size. Thanks. Dmitry. > hi Dmitry. > > > > […] > > We discussed how we could best cooperate to get phpng and this patch > together to ease everyone's work. > > > […] > > 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. > > > […] > > Again. This patch is about clean, safe, standard implementation for > 64bit plaforms and modern compilers, by far not only for windows > (which has one more gain with this patch, portability). It brings a > lot of guards, as well as safe and clean implementations. This is > something we should have done a long time ago. PHP is only of the only > OSS language I know still relying on old types and using integer for > buffer length. This is a bad practice and a well known troubles > source. To reduce it to only windows is hardly a good move. > > > […] > > 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. > > But rejecting a safe and clean 64bit support for a prototype, even > promising, is wrong, in so many ways. See below. > > > […] > > I can imagine a lot of things but at this point phpng is a very good > prototype with promising results. There is a good base idea and a lot > of changes in many places improving performance. However it is very > far away from being ready, APIs are very inconsistent and painful to > use (mix of zend_string and char* usage, remaing or removal which may > not make sense or make the code way too complicated). > > > […] > > I do not think it is that useful for both of us to redo the > discussions about this patch and its goal. It is a necessary step for > 64bit support. It is also very hard to use a prototype, developed for > months privately and still being in very early pre-alpha/testing phase > as argument to reject these changes. However, as I told you, it would > be way better to do both together, for everyone. But you reject the > idea. We have to move forward to php-next and I do not think we can > afford to wait months until phpng is remotely usable or stable (at > least APIs wised). > > In any case, if the 64bit patch is accepted we will support you and > other with phpng as we always do, even before its RFC or proposal, > this is what I call cooperation and teamwork. > > Cheers. > Pierre --- ## #74155 — Pierre Joye — 2014-05-14T06:27:15+00:00 URL: https://externals.io/message/74148#74155 · In reply to: #74154 hi, > Pierre, > > you developed a patch that will negatively affect every PHP application, > just to use "modern" types... > it's completely not necessary step for 64-bit support. It is amazing that we have to argue about that in 2014. Again, it is not only about about just using it but to finally have a safe and clean 64bit implementation. Almost every other project did that years ago, recommendation from various compilers developers, security teams, etc. do recommend to implement 64bit support this way. We had issues because of the lack of usage of this well known standard. And now it is told that it is useless? I cannot agree with this statement, sorry. Now, about the numbers, which are based on a prototype, there are rooms for more improvements, we both know that. As our numbers show, based on 5.6 and 5.6+patch, the actual impact is much smaller. And this is without digging deeper or without looking at what would be possible when both phpng and this patch would be merged and improved together. We are smart people and good developers, and we both have very good contacts to compilers expert. We can reduce the impact even more and improve the phpng optimization as well. However, reducing the 64bit support to "only about allowing large string", only to 64bit integer for long or "only about using modern types" is wrong, and we again both know that. Cheers, Pierre @pierrejoye | http://www.libgd.org --- ## #74156 — Dmitry Stogov — 2014-05-14T07:01:23+00:00 URL: https://externals.io/message/74148#74156 · In reply to: #74155 How can you reduce memory overhead if you start using 64-bit number for class names and other entities? If you have been developing this patch for months, why didn't you make it already? I'll tell you - because it's impossible. Thanks. Dmitry. > hi, > > > > […] > > It is amazing that we have to argue about that in 2014. > > Again, it is not only about about just using it but to finally have a > safe and clean 64bit implementation. Almost every other project did > that years ago, recommendation from various compilers developers, > security teams, etc. do recommend to implement 64bit support this way. > We had issues because of the lack of usage of this well known > standard. And now it is told that it is useless? I cannot agree with > this statement, sorry. > > Now, about the numbers, which are based on a prototype, there are > rooms for more improvements, we both know that. As our numbers show, > based on 5.6 and 5.6+patch, the actual impact is much smaller. And > this is without digging deeper or without looking at what would be > possible when both phpng and this patch would be merged and improved > together. We are smart people and good developers, and we both have > very good contacts to compilers expert. We can reduce the impact even > more and improve the phpng optimization as well. > > However, reducing the 64bit support to "only about allowing large > string", only to 64bit integer for long or "only about using modern > types" is wrong, and we again both know that. > > > Cheers, > Pierre > > @pierrejoye | http://www.libgd.org --- ## #74157 — Pierre Joye — 2014-05-14T07:16:49+00:00 URL: https://externals.io/message/74148#74157 · In reply to: #74156 > How can you reduce memory overhead if you start using 64-bit number for > class names and other entities? > If you have been developing this patch for months, why didn't you make it > already? What I said is: rewamp the structs, which is something we did not want to do before the work on the engine itself began, design, discussions, etc. We really did not expect to see you guys coming with this prototype and pushing it hardly after having worked on it for months without mentioning it or contacting us a single time. I blame us for being cooperative and open. I will try to fix that, sorry. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #74158 — Zeev Suraski — 2014-05-14T07:52:41+00:00 URL: https://externals.io/message/74148#74158 · In reply to: #74151 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 --- ## #74159 — Christian Stoller — 2014-05-14T08:08:06+00:00 URL: https://externals.io/message/74148#74159 · In reply to: #74158 > 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 > > > […] > 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 --- ## #74160 — Ferenc Kovacs — 2014-05-14T08:12:18+00:00 URL: https://externals.io/message/74148#74160 · In reply to: #74158 > 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 > > Even though that I agree, that our current voting process is suboptimal, but I would rather see it fixed instead of ignoring the rules when it is inconvenient/plain wrong. What I do think is wrong with the current rfc, is that it states that it needs only 50%+1 of the votes for acceptance. The patch is big, it will affect every php installation (eg. not just some platforms), it changes the Zend Engine, and it requires some non-trivial effort from the extensions to support it, so even though that the direct impact on the userland isn't that big (code with long strings etc. which would fatal will now starts working, big numbers will overflow differently, etc.) I think it still mandates a 66%+1 vote. Just my 2 cents. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #74161 — Lester Caine — 2014-05-14T08:16:51+00:00 URL: https://externals.io/message/74148#74161 · In reply to: #74153 > > […] > 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. My personal impression is that phpng is yet another independent port of php just like HHVM and the like. These all target a particular area of PHP use and may not be suitable for 'home users'. As an alternative base for PHPNext it may have a better pedigree and to that end a decision needs to be made for the path forward. What seems totally out of place here is a vote on something which has no real target yet? Has phpng already been accepted as PHPNext? That PHPNext will be 64bit is a given? So what is the need for a vote on a 'detail that can be changed'? It's the detail elements that need to be agreed on ... not the principle of 64bit! Hopefully there is no plan to backport this to the PHP5 builds? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #74162 — Ferenc Kovacs — 2014-05-14T08:19:32+00:00 URL: https://externals.io/message/74148#74162 · In reply to: #74159 On Wed, May 14, 2014 at 10:08 AM, Christian Stoller wrote: > > […] > the > > […] > as > > […] > hit > > […] > as > > […] > only > > […] > IS_LONG > > […] > and > > […] > performance > > […] > > 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 > yeah, I think it would have been better to announce/share the phpng work a bit sooner, but I think there is more than that in the current arguments: the two RFCs have a conflict of interest, the phpng is focused on the performance improvements through smaller memory usage, while the size_t patch increases that, and the changes in phpng made the impact bigger. So if we include both of those in their current form, the best scenario which we can end up is clearing up the type system and introducing phpng without any visible performance impact. Of course this is only my understanding of the situation. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #74163 — Dmitry Stogov — 2014-05-14T08:21:13+00:00 URL: https://externals.io/message/74148#74163 · In reply to: #74159 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 wrote: > > […] > the > > […] > as > > […] > hit > > […] > as > > […] > only > > […] > IS_LONG > > […] > and > > […] > performance > > […] > > 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 --- ## #74164 — Ferenc Kovacs — 2014-05-14T08:22:49+00:00 URL: https://externals.io/message/74148#74164 · In reply to: #74161 > > > > […] > > My personal impression is that phpng is yet another independent port of > php just like HHVM and the like. These all target a particular area of PHP > use and may not be suitable for 'home users'. As an alternative base for > PHPNext it may have a better pedigree and to that end a decision needs to > be made for the path forward. What seems totally out of place here is a > vote on something which has no real target yet? Has phpng already been > accepted as PHPNext? That PHPNext will be 64bit is a given? So what is the > need for a vote on a 'detail that can be changed'? It's the detail elements > that need to be agreed on ... not the principle of 64bit! > > Hopefully there is no plan to backport this to the PHP5 builds? > > both the phpng and the size_t rfcs are targetting the next major version, none of them are accepted yet, both of those would/will be suitable for 'home users'. buth these are all public information, stated in the RFCs and discussed on internals@ which you seems to be subscribed on based on your replies to the list, so I'm not sure where the confusion comes from. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #74165 — Zeev Suraski — 2014-05-14T08:31:33+00:00 URL: https://externals.io/message/74148#74165 · In reply to: #74160 I agree, and I’m not suggesting we ignore it; I just pointed out it makes no sense that such a drastic low-level change will be forced on those who effectively maintain the low-level engine for all of us. I don’t have a magical solution on how to solve it at this point. I did suggest two solutions to the situations within the current voting process: 1. Clearly expressing the concerns Dmitry has about this patch in the Performance section, so that at least people know what’s on the table; And add another option – the option – the one that has the true userland implications (the parts related to IS_LONG), and mention clearly that this one will come with no meaningful performance (memory/CPU) drawbacks. 2. If the authors of the RFC object (which is within their right, of course) – appealing to voters to vote ‘no’ on this one, and create another RFC for the IS_LONG parts. Zeev Even though that I agree, that our current voting process is suboptimal, but I would rather see it fixed instead of ignoring the rules when it is inconvenient/plain wrong. What I do think is wrong with the current rfc, is that it states that it needs only 50%+1 of the votes for acceptance. The patch is big, it will affect every php installation (eg. not just some platforms), it changes the Zend Engine, and it requires some non-trivial effort from the extensions to support it, so even though that the direct impact on the userland isn't that big (code with long strings etc. which would fatal will now starts working, big numbers will overflow differently, etc.) I think it still mandates a 66%+1 vote. Just my 2 cents. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #74167 — Zeev Suraski — 2014-05-14T08:38:54+00:00 URL: https://externals.io/message/74148#74167 · In reply to: #74159 > 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? Dmitry communicated at least some of his concerns about this patch long ago, back in January. Of course that's back when phpng didn't yet exist, and the impact wasn't as big as it is now. This patch can undo partts of the gains Dmitry and team managed to painstakingly squeeze out of the engine's data structures. You self-admitted not being a developer (a C developer I guess) - but I'm sure you can imagine how painful it is to squeeze even 1% of performance gain out of an already extremely optimized piece of code - one that's been optimized for more than a decade - let alone 10-30%. This performance currency shouldn't be traded lightly. Performance isn't above all other things, but it is above changes which are purely theoretical and have no meaningful end user value. Zeev --- ## #74166 — Lester Caine — 2014-05-14T08:39:36+00:00 URL: https://externals.io/message/74148#74166 · In reply to: #74164 > Hopefully there is no plan to backport this to the PHP5 builds? > > both the phpng and the size_t rfcs are targetting the next major > version, none of them are accepted yet, both of those would/will be > suitable for 'home users'. > buth these are all public information, stated in the RFCs and discussed > on internals@ which you seems to be subscribed on based on your replies > to the list, so I'm not sure where the confusion comes from. Since original discussions were being targeted against PHP5 picking out where discussions have moved on is not easily obvious. I seem to recall this was originally targeted against PHP5? Have we reached a point where PHP5 has been 'frozen' and so PHPNext is the more detailed target today? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #74168 — Pierre Joye — 2014-05-14T08:43:05+00:00 URL: https://externals.io/message/74148#74168 · In reply to: #74158 > 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, What is amazingly disturbing, annoying and respectless is yet again Zend, who are in my humble opinion not the only key developers since very long, worked on a rewamp of the engine for months, without sending a single notice to the list neither ask for feedback, support, discussions about its design, etc. > 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). Since when do you care about rules? Broke them for opcache last year and it looks like it will happen again for this prototype. > 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. So, if I understand correctly, you are asking to kill 80% of the patch, reduce it to the only 64bit integer part. And what for? Because you did not want to communicate earlier about your work on the engine? Despite the numerous messages, discussions, status updates about many tasks related to the next major version. Excuse me, but this is actually not acceptable. Let alone the technical reasons why the 64bit patch is a must have, since long. > 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: Let me rephrase it without confusing other readers, hopefully. phpng as it is now is a prototype. Very promising one but still a prototype. It totally lacks any usable documentation to do tests, port existing extensions or any real life tests, unlike the 64bit patch, which provide everything and have been intensively tested since the very first day, publicly, openly and every result has been discussed here. > * Add the relevant performance feedback from Dmitry to the RFC, as well as > his concerns as the chief performance guy php.net has Get phpng in a state where we can actually work with it, then we may consider it. As you can see, we already provide support to bring it there. But we are far away for being done, and I am only talking about getting it up and running on common supported platforms. Design (APIs) and other improvement still have to be done. > * Provide an option for people to vote 'yes' for the IS_LONG size part only No. As it is not what we have to do. See the previous discussions and my previous answers in this thread. > 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. Learn to manage your team in a way that cooperation with php.net core developers better. Performance is nice and shiny, but it should not be done at the price of the overall healthiness of the PHP project. And it becomes slowly a habit to push hard things for random reasons or unstable/unfinished patches. The proposal remains the same. I am more than convinced that we should cooperate and get both in at the same time. There are always rooms for improvements and we will provide support in many ways to achieve them, as we always did. But asking to simply drop 80% of the patch for an unknown and moving target is not acceptable. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #74169 — Ferenc Kovacs — 2014-05-14T08:46:21+00:00 URL: https://externals.io/message/74148#74169 · In reply to: #74166 > > > > […] > > Since original discussions were being targeted against PHP5 picking out > where discussions have moved on is not easily obvious. I seem to recall > this was originally targeted against PHP5? > > Have we reached a point where PHP5 has been 'frozen' and so PHPNext is the > more detailed target today? > > I guess you are referring to the previous rfc of the size_t, which was targetting 5.6 and failed? https://wiki.php.net/rfc/size_t_and_int64 many of the no voters mentioned that they would support the rfc but not in a minor version hence the authors accepted and now tried to get in into the next major, and here we are atm. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #74170 — Pierre Joye — 2014-05-14T08:46:56+00:00 URL: https://externals.io/message/74148#74170 · In reply to: #74163 > yes. We discussed that patch with Pierre for hours, one hour at best, and memory consuption impact was minimal when we bench it using 5.6 as base. It can still be minimal using phpng as we did not yet did the necessary work there, obviously (remember? you guys announced it last week). > 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. That's your mistake. We are an opensource projects and ideas must be (I repeat, must be) discussed early instead of very late. It works for every other healthy OSS projects and I totally fail to see why Zend and related cannot do it in a community friendly way. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #74171 — Pierre Joye — 2014-05-14T08:49:48+00:00 URL: https://externals.io/message/74148#74171 · In reply to: #74169 > > > > […] > I guess you are referring to the previous rfc of the size_t, which was > targetting 5.6 and failed? > https://wiki.php.net/rfc/size_t_and_int64 > many of the no voters mentioned that they would support the rfc but not in > a minor version hence the authors accepted and now tried to get in into the > next major, and here we are atm. Excactly. And we would not have done it if we knew that Zend was working on a total rewamp. We would have rather focused on getting phpng done faster, from a usability, design point of view, while adding the necessary steps for a safe, clean and actual 64bit support. But we did not know, nobody knew it until last week. But now we are asked to trash months of work, openness and tests. Sorry, no. -- Pierre @pierrejoye | http://www.libgd.org --- ## #74172 — Dmitry Stogov — 2014-05-14T08:53:19+00:00 URL: https://externals.io/message/74148#74172 · In reply to: #74161 phpng is based on the same sources and 99% compatible. We are just changing the basement. it must be the basement for PHPNext, but we didn't start any discussions about that. We actually have a lot of work to do and spend most the time doing our best. We have no plans to backport it into PHP-5.6. PHP supports 64bit for ages, and this proposal has nothing common with 64bit support in general. It allows 2GB strings, but do you imagine a web application that need them? However, each big PHP site will have to "pay" for it. Thanks. Dmitry. > > > > […] > > My personal impression is that phpng is yet another independent port of > php just like HHVM and the like. These all target a particular area of PHP > use and may not be suitable for 'home users'. As an alternative base for > PHPNext it may have a better pedigree and to that end a decision needs to > be made for the path forward. What seems totally out of place here is a > vote on something which has no real target yet? Has phpng already been > accepted as PHPNext? That PHPNext will be 64bit is a given? So what is the > need for a vote on a 'detail that can be changed'? It's the detail elements > that need to be agreed on ... not the principle of 64bit! > > Hopefully there is no plan to backport this to the PHP5 builds? > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- Next page: https://externals.io/message/74148.md?page=2