Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74153
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c9J5mtTzqFxvQHka5w5zVoGOzXNaUeYec62X_LYLOPcxA@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>
Date: Wed, 14 May 2014 07:46:46 +0200
Message-ID: <CAEZPtU6L0TCyR+U-eEJnwfYbxfMRibpKB70_Ue5fTOHD4y_VAQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Dmitry Stogov <dmitry@zend.com>, Anatol Belski <anatol.php@belski.net>, 
	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 7:30 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Sorry, what did I miss here? Why cannot the phpng numbers be taken as
> "valid"?

At this stage, this is a key part of this sentence.

> The very same issue also exists in our current implementation. In
> phpng the relative hit is just larger, because the structures are more
> optimized.
>
> I think you shouldn't dismiss Dmitry's point just like that.

I do not and did not. I would love to see the same from the phpng
side, but it failed, for no valid reason.

> Having support
> for 64 bit integers on Windows and other LLP64 architectures - that's great.
> Making string lengths unsigned - that's great as well. But supporting
> strings larger than 4G or arrays with more than 4 billion elements

Very large string or arrays are only side effects, it does not change
the goals and benefits of these changes.

> - that
> does not seem very useful and unlike the other two changes, hurts memory
> usage. I wonder how many people would prefer having lower memory usage over
> having the ability to create arrays with 4 billion elements.

This is a biased argument, you know it, I know it. The key point is
not about the new maximum size of an array or string but the long due
clean and safe 64bit implementation, following well known good
practice (can be seen in almost all other OSS projects out there) and
standards.

> Independently of that: In a lot of the previous discussion people have many,
> many, many times asked that this patch be implemented without all those
> macros renames and zpp changes. I still have a hard time seeing the benefit
> of doing that. The zpp changes also conflict with phpng, because S has a
> different meaning (and imho for no good reason - it could just as well stay
> at s).

This can be adapted, this is  a details. It is also why I have tried
to get phpng and this patch along together and get both teams work
together. Cooperation in this case will be benefit for php as a whole
as more optimization can be achieve while keeping the safe&clean
implementation.

As of now, phpng has been worked on for the last months, totally
privately. And even if it looks promising it is still not remotely
ready to be actually proposed. However it does not prevent you to use
it to stop other improvements, which have been worked on for months,
publically, with continuous tests, status updates, etc. I am not sure
what is happening here is good for PHP.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org