Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74162
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.53 as permitted sender)
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 10:19:32 +0200
Message-ID: <CAH-PCH56vuK_knu43gQ2+0+nUi9SRt08=rOON7rxsRNTCcB+fQ@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=001a11c11d12181dbb04f957d7e8
Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c11d12181dbb04f957d7e8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 14, 2014 at 10:08 AM, Christian Stoller <stoller@leonex.de>wrot=
e:

> > 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 pa=
ss
> > 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 voti=
ng
> > 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 phpn=
g
> >> 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 ve=
ry
> >> useful
> >> and unlike the other two changes, hurts memory usage. I wonder how man=
y
> >> 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 thos=
e
> >> 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 f=
or
> 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
>

yeah, I think it would have been better to announce/share the phpng work a
bit sooner, but I think there is more than that in the current arguments:
the two RFCs have a conflict of interest, the phpng is focused on the
performance improvements through smaller memory usage, while the size_t
patch increases that, and the changes in phpng made the impact bigger.
So if we include both of those in their current form, the best scenario
which we can end up is clearing up the type system and introducing phpng
without any visible performance impact.
Of course this is only my understanding of the situation.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c11d12181dbb04f957d7e8--