Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74353
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.128.173 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU4mrOiBzbqZdvxbgxseGo3ZzwgiinkqsgLQEZebrAke6w@mail.gmail.com>
References: <CAEZPtU4mrOiBzbqZdvxbgxseGo3ZzwgiinkqsgLQEZebrAke6w@mail.gmail.com>
Date: Mon, 19 May 2014 14:11:28 +0400
Message-ID: <CA+9eiLsMtcYVSvzHW_oc1dXNrDBH8RQ-cb1MgKB5ef2i2mQX7g@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bd6c72297198004f9bdfc4b
Subject: Re: 64bit and phpng, votes and plans
From: dmitry@zend.com (Dmitry Stogov)

--047d7bd6c72297198004f9bdfc4b
Content-Type: text/plain; charset=UTF-8

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
>

--047d7bd6c72297198004f9bdfc4b--