RE: [PHP-DEV] [VOTE] 64 bit platform improvements for string length and integer

From: Date: Fri, 31 Jan 2014 04:16:09 +0000
Subject: RE: [PHP-DEV] [VOTE] 64 bit platform improvements for string length and integer
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi,


> -----Original Message-----
> From: Hannes Magnusson [mailto:[email protected]]
> Sent: Thursday, January 30, 2014 7:30 PM
> To: Stephen Zarkos
> Cc: [email protected]
> Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string
> length and integer
> 
> On Thu, Jan 30, 2014 at 6:59 PM, Stephen Zarkos
> <[email protected]> wrote:
> > Hi,
> >
> >> -----Original Message-----
> >> From: Hannes Magnusson [mailto:[email protected]]
> >>
> >> - To the casual observer, the performance stats look great!
> >>     ...But they are a lie. It doesn't matter how 5.5+size_t performs
> >> since 5.5 isn't the target branch.
> >>     Maybe there have been 5.6 specific performance improvements that
> >> this patch trashes when merged into 5.6?
> >
> > The branch/patch for this RFC is based against the master branch right now,
> and so that's what was tested against.
> >
> 
> Ok. Glad to be wrong. The description should clearly mention that then.
> And is still wrong, as it compares 5.5.8 against 5.6.0-alpha+size_t then, if I
> read you correctly?
> 

At this point I'm not really sure what numbers you need.  On the RFC there are perf results for
5.5.8 and from the str_size_and_int64 branch.  We also have results from 5.6.0-a1 on w.p.n (same
bench, just drop in different PHP versions).  Are you saying one must backport the patch to 5.5 for
you to be satisfied?



> 
> >> - The vote makes it look like its "now or never" (5.6 or nothing)
> >>     This means people don't have to understand the implications.
> >>     All they need to know is "64bit integers in PHP? Ok. That sounds
> >> logical, I'll vote +1".
> >>     Of course people will vote for that.
> >>     When you start thinking (given you have ever created an external
> >> PHP extension, which minority of our normal voters have) you'll
> >> realize how much more there is to this.
> >
> > Isn't that what the discussion is for?  Anyone voting must be following this
> list, otherwise how would they even know to vote?
> >
> 
> 
> - Following the voting feed
> - Seeing a voting subject on a mailinglist
> - Friend of a friend
> - Twitter
> - Click a link on the internet
> - Boredom
> - IRC
> - Text message from a friend
> - Billboard message from that homeless guy on the street light
> - Peer pressure
> - expertsexchange
> - ...
> 
> Just to name some.
> 
> I have been following this discussion and just noticed the vote was open
> because it was being discussed on IRC, not even on #php.pecl.
> And I didn't know it would be a "5.6 or nothing" - plus 2 other fundamentally
> wrong votes.

I don't want to argue about that.  I just thought it was silly to discredit the vote by
suggesting the current voters are ignorant and just happily clicking buttons because the feature
sounds good.  There's no point in that sort of dialog.

With all those distribution channels you mentioned I would hope we reach as many members as possible
that may be impacted by this change.  That's all the feedback we really need right now to
decide if this gets merged into 5.6, or if it should be punted to another release.


> I was hoping for yes/no vote - which case I would have voted +1 and we
> could work on better approach for the extensions in time for the 6.0 release
> which this clearly is the start of.

Two years from the release of 5.6.0, 5.5 will be EOL and extension developers can just focus on
compat with 5.6+ and 6.0 (assuming we ever see it).  At that time it would be nice IMHO if 5.6+ and
6.0 were as similar as possible, starting with this RFC.

Thanks,
Steve



Thread (132 messages)

« previous php.internals (#71816) next »