Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74168
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <db6f4b4c2d10f343d4c30ee66d82b0eb@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>
Date: Wed, 14 May 2014 10:43:05 +0200
Message-ID: <CAEZPtU7uB7=3-EXBTpFAsARhOaoWUhxR7Zg+gHcEj0iMjeN+iA@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: pierre.php@gmail.com (Pierre Joye)

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.

> 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