Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74176
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.220.169 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7uB7=3-EXBTpFAsARhOaoWUhxR7Zg+gHcEj0iMjeN+iA@mail.gmail.com>
References: <e5f19ac0089d24adc695fce93ad9bd9c.squirrel@webmail.klapt.com>
	<CA+9eiLuoJM5bwA46M_2YddTXYOhAwhii=9Ref7-NNeuRuBfW5A@mail.gmail.com>
	<CAEZPtU7zz=npjUhacwSBA6cz+kb9iBmn3fjkvYuAjqtiPQgJhw@mail.gmail.com>
	<CAF+90c9J5mtTzqFxvQHka5w5zVoGOzXNaUeYec62X_LYLOPcxA@mail.gmail.com>
	<db6f4b4c2d10f343d4c30ee66d82b0eb@mail.gmail.com>
	<CAEZPtU7uB7=3-EXBTpFAsARhOaoWUhxR7Zg+gHcEj0iMjeN+iA@mail.gmail.com>
Date: Wed, 14 May 2014 13:16:11 +0400
Message-ID: <CA+9eiLuXAswVRMAhA_tW7mdNL9jpOMt7PoVXURP3fPo5sgnXtA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11334c38aae47504f958a125
Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: dmitry@zend.com (Dmitry Stogov)

--001a11334c38aae47504f958a125
Content-Type: text/plain; charset=UTF-8

On Wed, May 14, 2014 at 12:43 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> On Wed, May 14, 2014 at 9:52 AM, Zeev Suraski <zeev@zend.com> wrote:
> > 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.
>

today I spent few hours in discussions instead of planned work...
In case we started phpng as you suggest in the state when we didn't exactly
know what to do, we just didn't have it now.
And actually, not only Zend employees were involved in development.

Thanks. Dmitry.


> > 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11334c38aae47504f958a125--