64bit and phpng, votes and plans

hi, First of all thanks everyone for voicing your opinion on this topic. Due to the mailing system issues, we extend the vote until nexts Friday, to avoid any possible complains about it. Now, about the RFC itself. I would like to first remind some critical points: - The memory usage is not increase by 8% but ~4% in real life usage: Wordpress master: 24.33Mb Wordpress str_size_and_int64: 25.72Mb delta 5.4% Symfony master: 26.59Mb Symfony str_size_and_int64: 27.19Mb delta 2.2% Drupal master: 23.46MB Drupal str_size_and_int64: 24.60Mb delta 4.63% - The main priorities we have been worked on are: . Stability This patch has been tested intensively since the very first proposal, based on 5.5, 5.6 and master. Largely used frameworks and applications have been used to valid the changes. Everything has been done publicly, snapshots builds have been provided, tests results, updates, etc. have been published and announced at regular intervals. . Correctness and safenes Correct typing and reduce risks by removing magic casting, warnings about time junglings, etc make PHP safer, cleaner and less errorprone, while drastically reduce the work to catch new issues. I highly recommend to read http://news.php.net/php.internals/74193 and the references listed there . Performance Performance is one of the key of PHP success. Everyone takes performance seriously and so we do. The 64bit patch does not impact performance. It is at worst as fast as before and in many cases it even runs faster. Now that these points may be more clear, I would like to explain what we plan to do given the sudden announce about phpng. First of all, I never repeat it enough, cooperation is the key to success. If you did not notice we put effort too to get phpng in a usable state as well, providing fixes, ports and tests (for what is testable at this point). As the current voting results show, it makes sense to target phpng instead of master for the 64bit patch. Not only because it is the community will but also because it will reduce the amount of work on both side while allowing more tweaks and improvements. We have been explained that already and Nikita summarized it pretty well in this post:http://news.php.net/php.internals/74284 As I have told earlier, stability and correctness are the top priorities in such work. It is then much easier to tweak a stable, well tested and correct implementation than trying to tweak, optimize, re arrange a stack of hacks. We have reached the stability and correctness stand. However, asking to take a moving and still not proposed target into account before voting on a finished, stable patch is a hard thing. It is not possible to merge it now without basically redoing everything from scratch, possibly many times. It is not uncommon to vote on a patch that will change. Let take opcache as an example, by the time it was proposed it was months away from being ready. We delayed the 5.5 release for it, much later than what was told. The only difference here, and with phpng when it will come to a RFC, is that we have ~2 years to get them rock solid. Please keep that in mind while voting. What we propose is the following: - get phpng in a alpha state, somehow testable in common scenarios (should take 2-3 months max) - merge the 64bit patch - do the improvements and tweaks we discussed (be ours or Nikita's), they will be based on real results and not some random moving targets, safer, cleaner, better (c) Doing so will bring the benefits of both patches to PHP without increase the work load for any of us (well, except for my team, that will cost us quite some time to do it). In the meantime, we will keep our effort to get phpng ready as soon as possible, by porting missing parts, fixing it, etc. I do think that this is a good and reasonable way of doing it. Thanks for having read this mail until here and for your upcoming votes or feedbacks. Cheers, -- Pierre @pierrejoye | http://www.libgd.org