Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74352
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.52 as permitted sender)
MIME-Version: 1.0
Date: Mon, 19 May 2014 11:44:41 +0200
Message-ID: <CAEZPtU4mrOiBzbqZdvxbgxseGo3ZzwgiinkqsgLQEZebrAke6w@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, Dmitry Stogov <dmitry@zend.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: 64bit and phpng, votes and plans
From: pierre.php@gmail.com (Pierre Joye)

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