Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74163
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.128.175 cause and error)
MIME-Version: 1.0
In-Reply-To: <4ED7146272E04A47B986ED49E771E347BBDA6AAA06@Ikarus.ameusgmbh.intern>
References: <e5f19ac0089d24adc695fce93ad9bd9c.squirrel@webmail.klapt.com>
	<db6f4b4c2d10f343d4c30ee66d82b0eb@mail.gmail.com>
	<4ED7146272E04A47B986ED49E771E347BBDA6AAA06@Ikarus.ameusgmbh.intern>
Date: Wed, 14 May 2014 12:21:13 +0400
Message-ID: <CA+9eiLuqXs4f87bLb-vGL6AB=eEbR5khR1WtoVLwS0au7EpCOg@mail.gmail.com>
To: Christian Stoller <stoller@leonex.de>
Cc: Zeev Suraski <zeev@zend.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf302efaf611eb0f04f957dde1
Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: dmitry@zend.com (Dmitry Stogov)

--20cf302efaf611eb0f04f957dde1
Content-Type: text/plain; charset=UTF-8

yes. We discussed that patch with Pierre for hours, and I always told that
I afraid about memory consumption overhead.
my tests showed it clearly

phpng was started as closed project, because we didn't know if we'll able
to succeed at all (it's not a first attempt) and we liked to move fast.
Once, we got useful results we opened it.
see https://wiki.php.net/phpng#performance_evaluation

Thanks. Dmitry.


On Wed, May 14, 2014 at 12:08 PM, Christian Stoller <stoller@leonex.de>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, 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).
> >
> > 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.
> >
> > 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:
> >
> > * Add the relevant performance feedback from Dmitry to the RFC, as well
> as
> > his concerns as the chief performance guy php.net has
> > * Provide an option for people to vote 'yes' for the IS_LONG size part
> only
> >
> > 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.
> >
> > Zeev
> >
> >> Sorry, what did I miss here? Why cannot the phpng numbers be taken as
> >> "valid"?
> >> 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. 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 - 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.
> >>
> >> 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).
> >>
> >> Nikita
> >
>
> I am not a developer, but I think the approach of the phpng developers is
> not fair. The 64 bit topic and its RFC has been worked on and discussed for
> weeks or months and now theirs suddenly phpng and all the former work
> should be thrown away?
>
> I have not followed the whole discussion about 64 bit/size_t, etc, so I
> just want to ask if you, Nikita, Dmitry or Zeev have mentioned your view
> and the issues before?
>
> Christian
>

--20cf302efaf611eb0f04f957dde1--