Re: 64bit and phpng, votes and plans

Hi Pierre, I appreciate your professionalism in helping with phpng. I object against the proposal, because in my opinion, it makes significant degradation even for master. (Please don't argue about it again. You have your opinion, I have mine, we already wrote a lot). I also think, it makes sense to target at least IS_LONG part of this patch to phpng. Other changes are questionable. In phpng we may relatively easy check the impact of 64-bit string size on performance and memory consumption to make a decision. I don't have any special opinion right now. I didn't get your position about zend_size_t in all core structures. And this is the main question. Thanks. Dmitry. On Mon, May 19, 2014 at 1:44 PM, Pierre Joye <pierre.php@gmail.com> wrote: > 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 >