[PHP-DEV] Re: [RFC] RNG fixes

[Tom Worster]

Hi Leigh,

I need to change stance wrt MT.


On 6/16/16, 2:31 PM, "Leigh"  wrote:

>I get your point, but most people probably use mt_rand() because "it's
>better than rand". mt_rand is also incredibly slow and has a huge state
>when compared to modern algorithms. I should probably note the
>performance gains in the RFC.

I spent some time trying to understand the weird PHP mt_rand(). I took the
binary MT19937_02 generator from TestU01 and made a variant with the PHP
bug. I added side-by-side diff off the results from running BigCrush on
both here 

https://gist.github.com/tom--/a12175047578b3ae9ef8

I can't see any significant difference between.

More interesting was how this work changed my appreciation of Mersenne
Twister. I used to think it was a good RNG. But that dates back a long
time to when George Marsaglia had the best tests for RNGs and he was
challenging sci.math to factor enormous numbers to use in new generators
with ever more extravagant periods. I took it on authority that MT was
decent. 

But after spending time with the code I see you're right! Its state and
period are crazy. It's one thing to be slow but on top of that it's
chewing up cache lines as though nothing else needs them.

My opinion on rand() is that it is historical, like the crummy old RNGs
kicking around in various libcs and elsewhere. Don't use them. Now I feel
the same about mt_rand() -- like MD4 and DES, it's interesting history.

I think every self-respecting programming environment should provide a
good deterministic RNG. And now it seems I've persuaded myself that it's
time time for PHP to move on from MT.

So I need to update my opinion on your RFC. I still think rand() and
mt_rand() implementations can stay but I now agree with you that it's time
for a new RNG. And I agree that xoroshiro128+ is a good choice.

Specifically, rand() docs should say that the underlying RNGs are
obsolete, not portable and have questionable quality on some platforms.
mt_rand() docs should mention the poor performance and reference #71152.

Tom



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Accepted] Replace "Missing argument" warning with "Too few arguments" exception

[Davey Shafik]

On Wed, Jun 15, 2016 at 11:25 PM, Dmitry Stogov  wrote:

> Hi Pierre,
>
>
> On 06/16/2016 09:18 AM, Pierre Joye wrote:
>
>>
>> Hi Dmitry
>>
>> I am sorry but I have to ask to wait before merging it.
>>
>>
> Sorry, but this is already merged.
>
>>
>> It is definitely not clear that:
>>
>> . The rfc was valid to begin with due to the short discussion time
>> . This BC is acceptable for 7.x
>>
>> I think things like things can be prevented by following the relatively
>> simple rfc process and having a more clear way to define what is acceptable
>> as BC.
>>
>>
> I think, the decision of the majority of voters, told that the BC break is
> minor and acceptable for 7.1.
> The only mistake was in shorten discussion period.
>
>>
>> I think the RMs should step in here.
>>
>>
> Yeah, I suppose, RMs may have a right to take a decision and revert this.
>
> Thanks. Dmitry.


As I said in earlier discussions, the fact we cannot measure potential
impact makes me very hesitant to include this change. Again: if I were the
sole RM I _would_ try to veto this change.

I understand the desire to get this out in 7.1, we will never have a time
when 7.x has less users than it does now, and we don't want to wait for 8.0.

IMO a better compromise would have been to add an E_DEPRECATED noting that
it would be changed in 7.2, and then doing so. Is something like this still
a possibility?

I know that Joe feels strongly about this particular change being merged
in, and it is done now. We should address similar situations moving
forward, and move on.

- Davey

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Rowan Collins]

On 16/06/2016 19:11, Levi Morrison wrote:

On Thu, Jun 16, 2016 at 10:30 AM, Rowan Collins  wrote:


>
>Why? What's special about 7.1? If it was a case of finishing off changes
>that "should have been part of 7.0", I can see some kind of logic, but the
>ones we're actually discussing seem to be more about "preparing for 8.0".

I didn't necessarily mean the currently proposed; I mean more
generally. For instance Nullable Types and the associated
ReflectionType changes both have small BC breaks that I don't mind. In
the case of the former there is a long-standing bug that did have BC
break impact that was fixed.


Ah, fair enough, thanks for clarifying.

As noted before, the nullable types case included careful analysis of 
small BC breaks that were a side-effect of a major new feature being 
released as part of 7.1. I wouldn't personally draw a distinction in  
between adding it in x.1 vs x.2 or x.3; either the BC hiccup is 
acceptable, or the feature should be roadmapped to x+1.0.


But the ReflectionType case definitely feels like clean-up of 7.0, so 
makes sense to me as an example.


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] RNG fixes

[Pierre Joye]

On Jun 17, 2016 1:55 AM, "Fleshgrinder"  wrote:
>
> On 6/16/2016 8:14 PM, Pierre Joye wrote:
> > Well know you do as I gave you examples of such usages. Their Code not
> > public so I cannot give you links.
> >
>
> That's a knockout argument.
>
> On 6/16/2016 8:14 PM, Pierre Joye wrote:
> > I am not sure to follow the legitimate part. There are perfectly
legitimate
> > usage of rand/mt_rand outside crypto. The fact that some developers
still
> > do not get the non safe part is an education problem. The same applies
to
> > many functions, like serialize, which has many security impacts but we
do
> > not remove it because some people misuse it constantly.
> >
>
> Nikic sees it like I do:
>
> https://wiki.php.net/rfc/deprecations_php_7_1#rand_srand_and_getrandmax

Nothing there says anything about dropping mt_rand or make it mon standard
using "modern" algorithms. As I said earlier, to have a std MT
implementation is a good thing. I am only not sure about the implications
of changing it now by default.

> People are already preparing for it:
>
> https://github.com/SimpleMachines/SMF2.1/issues/3492
>
> And apparently people who want to create tiny games don't get it right:
>
> https://github.com/Frug/AJAX-Chat/issues/167
>
> I am still going through the search results. So far everything deals
> with broken crypto and invalid usage of rand(), srand() as well as
> mt_rand() and mt_srand(). I know you will continue insisting that this
> is a super crucial feature just because you started with this argument
> into this discussion. I learned that people in general have a hard time
> changing their mind a long time ago.

Generalities do not apply to people or code.

I can change my mind but not about dropping it to improve security as it is
the wrong side of the problem.

Let me know if my point is not clear (not rejecting the improvements but
the drop and default behaviours) but at no point I said it is a "super
crucial" feature. I only consider as yet another change that can and will
break codes by default does a false sense of security (use php_random for
security purposes or the compatibility package).

> > A designer knows he has achieved perfection not when there is nothing
> > left to add, but when there is nothing left to take away.
> >
> > --- Antoine de Saint-Exupery
>
> Education is a hard problem that the whole world is struggling with. We
> will never achieve it. We will especially not achieve convincing people
> of legacy software to change. Heck, we cannot even convince anyone here
> to change legacy stuff. Hence, if rand and friends stay, they will
> continue to help people to produce insecure software.
>
> On 6/16/2016 8:14 PM, Pierre Joye wrote:
> > It does as these functions are available by default and cannot be
disabled
> > (ext/standard).
> >
>
> And? That is beside the point. People can simply add the PECL module and
> there is no difference. We could deprecate them and move them to PECL
> later. There are many ways.
>
> Changing the behavior of any of these functions *is* a BC for the
> software that you refer to that relies on the predictability of these
> functions. Somehow it seems that you are fine with that ...?!?
>
> --
> Richard "Fleshgrinder" Fussenegger
>

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Fleshgrinder]

On 6/16/2016 9:13 PM, Stanislav Malyshev wrote:
> Hi!
> 
>> it into 7.0 is plain wrong and only creates problems. Everyone is always
>> so concerned about breaking something if someone proposes some
>> deprecation but in such cases nobody cares.
> 
> Because it's not about how it's proposed, but is about what impact it
> will have on users. If you try to deprecate feature that is widely used,
> you'd get a lot of pushback. If you try to change something that nobody
> is using and nobody should be using, you'd get little to no pushback.
> 

Hey! :)

That does not match your usual argumentation which goes along the lines
that people expect a stable language and that they will turn to other
languages that are more stable if the language is not stable. We are
making the language unstable. Deprecating things and offering better
alternatives with a clear upgrade path is not breaking things, it is
improving. We are improving something in this case but without prior
notice and break stuff. Stuff we simply don't know of and cannot judge
at all.

I am still in favor if this change, fully and completely, as it is the
right thing to do and it helps catching bugs. I am even in favor of
adding more errors like this for other stuff like optional arguments
before non-optional ones. However, we need to prepare our users for that
(like with deprecations), inform them up front, and use the version
numbers to communicate that things will be broken. Many people do not
bother reading a CHANGELOG, following internals, or caring at all about
the language development. Hence, the pushback always comes later but
then it is too late.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Stanislav Malyshev]

Hi!

> it into 7.0 is plain wrong and only creates problems. Everyone is always
> so concerned about breaking something if someone proposes some
> deprecation but in such cases nobody cares.

Because it's not about how it's proposed, but is about what impact it
will have on users. If you try to deprecate feature that is widely used,
you'd get a lot of pushback. If you try to change something that nobody
is using and nobody should be using, you'd get little to no pushback.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] RNG fixes

[Fleshgrinder]

On 6/15/2016 1:01 PM, Christoph Becker wrote:
> I don't know, but I can image that it is (test suites come to mind).  Of
> course, it might be an option to move the functionality to PECL, but on
> the other hand, what would we gain?  For users, however, that might be a
> major pain; consider software which runs on shared hosting.
> 

https://github.com/sebastianbergmann/phpunit/pull/1408#issuecomment-53163159

rand() will not work for them. ;)

And then there is https://packagist.org/packages/leigh/mt-rand as Leight
just pointed out.

I am sorry but this topic is clear as a crystal.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] RNG fixes

[Fleshgrinder]

On 6/16/2016 8:14 PM, Pierre Joye wrote:
> Well know you do as I gave you examples of such usages. Their Code not
> public so I cannot give you links.
> 

That's a knockout argument.

On 6/16/2016 8:14 PM, Pierre Joye wrote:
> I am not sure to follow the legitimate part. There are perfectly legitimate
> usage of rand/mt_rand outside crypto. The fact that some developers still
> do not get the non safe part is an education problem. The same applies to
> many functions, like serialize, which has many security impacts but we do
> not remove it because some people misuse it constantly.
> 

Nikic sees it like I do:

https://wiki.php.net/rfc/deprecations_php_7_1#rand_srand_and_getrandmax

People are already preparing for it:

https://github.com/SimpleMachines/SMF2.1/issues/3492

And apparently people who want to create tiny games don't get it right:

https://github.com/Frug/AJAX-Chat/issues/167

I am still going through the search results. So far everything deals
with broken crypto and invalid usage of rand(), srand() as well as
mt_rand() and mt_srand(). I know you will continue insisting that this
is a super crucial feature just because you started with this argument
into this discussion. I learned that people in general have a hard time
changing their mind a long time ago.

> A designer knows he has achieved perfection not when there is nothing
> left to add, but when there is nothing left to take away.
>
> --- Antoine de Saint-Exupery

Education is a hard problem that the whole world is struggling with. We
will never achieve it. We will especially not achieve convincing people
of legacy software to change. Heck, we cannot even convince anyone here
to change legacy stuff. Hence, if rand and friends stay, they will
continue to help people to produce insecure software.

On 6/16/2016 8:14 PM, Pierre Joye wrote:
> It does as these functions are available by default and cannot be disabled
> (ext/standard).
> 

And? That is beside the point. People can simply add the PECL module and
there is no difference. We could deprecate them and move them to PECL
later. There are many ways.

Changing the behavior of any of these functions *is* a BC for the
software that you refer to that relies on the predictability of these
functions. Somehow it seems that you are fine with that ...?!?

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Re: [RFC] RNG fixes

[Leigh]

RFC updated to include:
* A note about mt_rand()s poor performance
* Separate votes for proposals so we can at least get the security fixes
through
* Updated vote from 50% to 2/3 as it does cause a BC issue.

I should also state that mt_rand is easily implementable in userland, so
the correct/legacy algorithm can be provided that way if changing it in
core does not pass (I have a library providing this)

So there have been a couple of suggestions of providing legacy
functionality via a PECL extension. If we were to make rand/mt_rand use
function pointers to their implementation it would be very easy for an
extension to override their behaviour. If people like this idea I'm more
than happy to provide this ext as part of the RFC.

Re: [PHP-DEV] [RFC] RNG fixes

[Leigh]

On Wed, 15 Jun 2016 at 14:05 Jordi Boggiano  wrote:

> Just a thought here, if the goal is to provide a better interface,
> wouldn't it be better to use OO for this? Not because OO is better, but
> because it would avoid having problems if two mt_rand-using pieces of
> code are executed concurrently.


The goal is to fix inconsistencies. We absolutely can provide a better
interface as something separate though.

[PHP-DEV] Re: [RFC] RNG fixes

[Leigh]

On Wed, 15 Jun 2016 at 00:08 Tom Worster  wrote:

> On 6/14/16 12:46 PM, Leigh wrote:
>
> > The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
>
> Hi Leigh,
>
> Thanks for putting this together. I am strongly pro on two points and
> moderately contra on the other two. I'd prefer separated votes, even
> though I don't have a vote. I numbered the 4 bullets in your intro 1 thru
> 4.
>

Noted, even though I'd like to "fix everything" at once, if separating the
votes is the only way to get the most important fixes in, then that's what
we'll have to resort to.


> 4. Insecure usage. I think we should replace the internal insecure uses
> of php_rand(). I can't see a reason not to.
>
> 3. Poor scaling of bounded outputs. I think RAND_RANGE() should be
> fixed. Users surely expect unbiased distribution. There's a BC argument
> but the bug is pretty serious. I think this should apply to array_rand()
> too.
>

Every point on the list causes a BC issue, it's up to us to judge which
ones are worth it. Some independent and some cascade into each other. I
just don't want to be in a situation where we cause some now, and some in a
future version.

1. Incorrect implementations.
>
> I don't think we should dictate that programs currently using mt_rand()
> shall use in future use MT19937 any more than we should dictate that
> XorShift64 or any other PRNG better fits their requirements.
>

I get your point, but most people probably use mt_rand() because "it's
better than rand". mt_rand is also incredibly slow and has a huge state
when compared to modern algorithms. I should probably note the performance
gains in the RFC.


> The incorrectness of the mt_rand() implementation with respect to its
> documentation can be fixed either in the code or in the docs. Given
> that, as far as we know, mt_rand()'s byte-stream looks like a decent
> PRNG[1] it's not clear that the actual MT19937 sequence is more
> important that backward compatibility. I for one think it's very unlikely.
>

I actually agree, (it was me who originally reverted the mt_rand fix in a
point release, citing BC as my reason to do so). I felt obligated to put
the decision up for a vote though, because I might have been wrong :)

I also don't think we should assume the responsibility of correcting
> people's insecure programs using rand() or mt_rand() (e.g. for keys,
> IVs, salts) by changing the algorithm. Programs this bad need more
> rework than we can provide. These functions have had scary-colored
> cautions on them for a long time.
>

We can only educate so far, I think we do have an obligation to provide the
best (no matter how subjective) possible algorithms to the end users.

Summarizing 2. and 3. it's not clear what we fix in the real world with
> the proposed changes to rand() and mt_rand(). But I do see BC breakage.
> I would prefer to fix these bugs the docs.
>

Changing mt_rand I don't see any real gain, but rand on the other hand has
platform-dependant output.

With respect to PRNGs completely new to PHP (you mentioned Xoroshiro128+
> and PCG), I would prefer completely divorce this question from the bugs
> discussed above. If some PHP users need efficient implementations of
> such algorithms then I would urge whoever wants to write them to use a
> new API and to provide them via PECL. In software, "better" is always
> with respect to context. While there are specific, well-known uses for
> random numbers (e.g. crypto) where we can make recommendations, in
> general we cannot.
>

I've been thinking of doing this anyway.

Re: [PHP-DEV] [RFC] RNG fixes

[Pierre Joye]

On Jun 17, 2016 12:43 AM, "Fleshgrinder"  wrote:
>
> On 6/16/2016 4:21 AM, Pierre Joye wrote:
> > No they don't all do it.
> >
>
> We don't know but I will try to find legitimate usages of (mt_)rand.

Well know you do as I gave you examples of such usages. Their Code not
public so I cannot give you links.

I am not sure to follow the legitimate part. There are perfectly legitimate
usage of rand/mt_rand outside crypto. The fact that some developers still
do not get the non safe part is an education problem. The same applies to
many functions, like serialize, which has many security impacts but we do
not remove it because some people misuse it constantly.

> On 6/16/2016 4:21 AM, Pierre Joye wrote:
> > There are ways to achieve what you want in a nice way while not breaking
> > things. Let consider them.
> >
>
> Moving to PECL does not break anything.

It does as these functions are available by default and cannot be disabled
(ext/standard).

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Levi Morrison]

> I didn't necessarily mean the currently proposed; I mean more
> generally. For instance Nullable Types and the associated
> ReflectionType changes both have small BC breaks that I don't mind. In
> the case of the former there is a long-standing bug that did have BC
> break impact that was fixed. This passed 44 to 1. Stas was the no-vote
> and he can clarify his stance but I do not believe he voted no because
> of the BC break.

Correction; 44 to 2. The other vote was Bwoebi's and he would prefer
full union types.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Levi Morrison]

On Thu, Jun 16, 2016 at 10:30 AM, Rowan Collins  wrote:
> On 16/06/2016 17:24, Levi Morrison wrote:
>>>
>>> I also have to say that to the very short timeline to finalize 7.0
>>> should not be paid by breaking BCs in 7.x. We can have a short
>>> timeline for 8.0 as well. If we need more drastic BC breaks earlier
>>> than expected. If JIT is a goal for 8.0, then let do the BC breaks in
>>> 8.0 and prepare our users using 7.x.
>>
>>
>> I agree with sentiment. However I do not mind certain BC breaks being
>> made in 7.1. For 7.2 and beyond I think we should be significantly
>> more strict on BC breakages.
>
>
> Why? What's special about 7.1? If it was a case of finishing off changes
> that "should have been part of 7.0", I can see some kind of logic, but the
> ones we're actually discussing seem to be more about "preparing for 8.0".

I didn't necessarily mean the currently proposed; I mean more
generally. For instance Nullable Types and the associated
ReflectionType changes both have small BC breaks that I don't mind. In
the case of the former there is a long-standing bug that did have BC
break impact that was fixed. This passed 44 to 1. Stas was the no-vote
and he can clarify his stance but I do not believe he voted no because
of the BC break.

In the case of ReflectionType it's cleaning up an API that was only
introduced in 7.0 to be better integrated with nullable types before
too many people are relying on it.

I think both of these BC breaks are reasonable for a minor that is
immediately following a major.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] RNG fixes

[Fleshgrinder]

On 6/16/2016 4:21 AM, Pierre Joye wrote:
> No they don't all do it.
> 

We don't know but I will try to find legitimate usages of (mt_)rand.

On 6/16/2016 4:21 AM, Pierre Joye wrote:
> There are ways to achieve what you want in a nice way while not breaking
> things. Let consider them.
> 

Moving to PECL does not break anything.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Fleshgrinder]

On 6/16/2016 6:30 PM, Rowan Collins wrote:
> On 16/06/2016 17:24, Levi Morrison wrote:
>>> I also have to say that to the very short timeline to finalize 7.0
>>> should not be paid by breaking BCs in 7.x. We can have a short
>>> timeline for 8.0 as well. If we need more drastic BC breaks earlier
>>> than expected. If JIT is a goal for 8.0, then let do the BC breaks in
>>> 8.0 and prepare our users using 7.x.
>>
>> I agree with sentiment. However I do not mind certain BC breaks being
>> made in 7.1. For 7.2 and beyond I think we should be significantly
>> more strict on BC breakages.
> 
> Why? What's special about 7.1? If it was a case of finishing off changes
> that "should have been part of 7.0", I can see some kind of logic, but
> the ones we're actually discussing seem to be more about "preparing for
> 8.0".
> 
> Regards,

I agree fully with Rowan. Squeezing in those features that did not make
it into 7.0 is plain wrong and only creates problems. Everyone is always
so concerned about breaking something if someone proposes some
deprecation but in such cases nobody cares.

This is a very bad attitude!

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

[Stanislav Malyshev]

Hi!

> Please review: https://wiki.php.net/rfc/constant_redefinition

I would propose to not throw an error if constant is redefined to
exactly the same value. Some of the code might be doing this
unknowingly, e.g. by writing include instead of include_once, and
there's no real reason to break it.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Rowan Collins]

On 16/06/2016 17:24, Levi Morrison wrote:

I also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.


I agree with sentiment. However I do not mind certain BC breaks being
made in 7.1. For 7.2 and beyond I think we should be significantly
more strict on BC breakages.


Why? What's special about 7.1? If it was a case of finishing off changes 
that "should have been part of 7.0", I can see some kind of logic, but 
the ones we're actually discussing seem to be more about "preparing for 
8.0".


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Levi Morrison]

> I also have to say that to the very short timeline to finalize 7.0
> should not be paid by breaking BCs in 7.x. We can have a short
> timeline for 8.0 as well. If we need more drastic BC breaks earlier
> than expected. If JIT is a goal for 8.0, then let do the BC breaks in
> 8.0 and prepare our users using 7.x.

I agree with sentiment. However I do not mind certain BC breaks being
made in 7.1. For 7.2 and beyond I think we should be significantly
more strict on BC breakages.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-06-16

[lp_benchmark_robot]

Results for project PHP master, build date 2016-06-16 06:29:42+03:00
commit: fba6f90
previous commit:3389c2e
revision date:  2016-06-15 22:52:48+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.22%  0.03%  1.20%  
  6.12%
:-|   Drupal 7.36 cgi -T1  0.17%  0.19%  0.28%  
  3.94%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09%  0.19%  1.69%  
  2.66%
:-(   bench.php cgi -T100  0.02% -1.26% 27.60%  
 -0.46%
:-(  micro_bench.php cgi -T10  0.01% -1.26%  3.67%  
  3.47%
:-|  mandelbrot.php cgi -T100  0.01%  0.79% 31.20%  
  1.19%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2016-06-16/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x

[Alexander Lisachenko]

2016-06-15 22:28 GMT+03:00 Niklas Keller :

> didn't read it was planned for all file functions.



Let's restrict my first suggestion only for "require" expression for now.
So proposal is following:

Rewrite "require" to throw an Error instead of current Fatal Error if some
file can not be loaded. This is fully BC and can be merged into 7.0 and
7.1, because it's impossible to catch a fatal error now. This will be
consistent with handling of eval errors - now we use the ParseError
exception instead of fatal errors.

In my opinion, all fatal errors should be replaced with exception throwing
(if possible), because it's more developer-friendly and allow us to handle
failures gracefully, invoking finally, destructors, etc.

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Rowan Collins]

Hi Joe,

On 16/06/2016 05:40, Joe Watkins wrote:

   > Please don't let's make it harder to go from 7.0 to 7.1 than it was
from 5.6 to 7.0.

   Can we reduce hyperbole to nil, please.


Sorry, yes, that was a bit hyperbolic on my part. I do think there is 
the risk of making 7.0 to 7.1 as awkward an upgrade as 5.3 to 5.4, though.


The main problem I've encountered in 5.4 is the removal of the 
already-deprecated call-time pass-by-reference, because it is an 
invasive change that can't be worked around: you can't even test what 
other impact the upgrade had until you've fixed it.


And at least that one could be detected with static code analysis; I'm 
not even sure how to know if a code base would be affected by too_few_args.




   Before work starts on PHP 8, we need to have something worth
branching, just as we needed for 7, and 6.


Again, this idea of a minimum requirement for PHP 8. I still haven't 
seen anyone explain exactly what this means. If we have a bunch of 
breaking changes, and those breaking changes are justified, then we can 
justify a major release.




The majority have decided that the *extremely minor* BC break is worth the 
tradeoff.


Absolutely, a majority of voters have indicated that, while a minority 
indicated they would support it in an 8.0 release. There's no reason we 
have to accept "good enough" if we can agree a plan that is even better.


One thing I haven't seen stated very clearly is why there is a rush to 
get this feature into a live release right now, with 7.1 already in 
alpha. Is the plan to release major performance changes in 7.1.x? 
Wouldn't most of those have to wait for 7.2.x anyway?


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

[Lester Caine]

On 16/06/16 07:44, Dmitry Stogov wrote:
> RFC also proposes a way to "fix" affected applications, wrapping constant 
> definitions, that may be redefined, with try/catch.

Doesn't anybody remember the problems which STILL have to be resolved
with changes in PHP5.2/3/4 which require the assistance of programmers
to fix naive users problems. Now many of the new features being added
will not be currently used in legacy code, but can anybody ensure that
all of the BC changes being currently pushed for will not cause a more
general PHP5.4 style block to upgrading?

HAVING to add changes to code to retain a legacy style of operation is
something that should only happen in a major version. Isn't this why
most big projects no longer bother with many small version changes? What
is Firefox up to now ...

However going down that root does require LTS builds which is something
else which is maintaining PHP5.3 in the field. I am now getting used to
the changes in PHP7, but the current roadmap for PHP7.1 is just another
PHP5.4 in my book and it does create a case for my simply rolling back
to PHP5 since none of my production systems have been fully updated so
they can use PHP7 yet ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [OpenSSL] Support for ECC public key generation

[Dominic Luechinger]

On 15/06/16 03:51, Scott Arciszewski wrote:
> While we're at it, can we also add a function to generate (ephemeral)
> Elliptic Curve Diffie-Hellman keys, and then use openssl_dh_compute_key()
> with ECDH keys? Because that would be a lot saner than having to
> shell_exec() to the OpenSSL binary in userland.

Thank you for pointing out ECDH. It makes sense to extend the ECC
support even further.

What do you mean by:
> generate (ephemeral) Elliptic Curve Diffie-Hellman keys

For a ECDH to be ephemeral you could just create a new ECC key pair.
This is now possible with this extension.

As you pointed out the missing part is that openssl_dh_compute_key not
supporting ECC keys. This was requested in the past [1].
If hacked together a proof of concept for openssl_ecdh_compute_key().
I'll push this update to a new branch. I'll send you an update if the
branch is ready for testing.

Regards

Dominic

[1] https://bugs.php.net/bug.php?id=71548

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

[Pierre Joye]

On Jun 11, 2016 4:27 AM, "Dmitry Stogov"  wrote:
>
> In general, you are right, but this is possible only if application
ignores Error exceptions...

Exactly.

Many if not hundred of applications do not even use exception but if a
couple of places, let alone plug-ins for these apps.

Most of these apps is what I called main stream applications. They are
provided as SaaS or ready to be installed. The providers taking care of the
system parts, php included.

Now what will happen if they update and exception start to be throw for
that?

Right, they will downgrade or not update at all for the good ones (tested).

To me it sounds like a pretty bad plan to ease the migration path.

In other words, it looks to me that you are working on something bigger,
early phase. This things seems to require more and more clean paths and
rules.

This is alone is something to justify to start to plan 8. And we all know
Jit will be for 8. Let start even if the Jit itself is not even officially
started.

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

[Dmitry Stogov]

The voting dates was changed to Jun 24 (to satisfy 2 weeks discussion period).


In my opinion the BC break is minimal.

Actually, the "wrong" behavior was reported by 
https://bugs.php.net/bug.php?id=71127

Before this, opcache worked "improperly" for few years (at least since php-5.4).

Unfortunately, we fixed https://bugs.php.net/bug.php?id=71127 too later and 
weren't able to fix PHP-7.0 "properly".


Now I propose a safer and more consistent way of handling attempts of constants 
redefinition.

RFC also proposes a way to "fix" affected applications, wrapping constant 
definitions, that may be redefined, with try/catch.


Thanks. Dmitry.


From: Dmitry Stogov
Sent: Friday, June 10, 2016 11:06:55 PM
To: PHP internals
Subject: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition


Hi internals,


Please review: https://wiki.php.net/rfc/constant_redefinition


Thanks. Dmitry.

Re: [PHP-DEV] [RFC] [Accepted] Replace "Missing argument" warning with "Too few arguments" exception

[Dmitry Stogov]

Hi Pierre,


On 06/16/2016 09:18 AM, Pierre Joye wrote:


Hi Dmitry

I am sorry but I have to ask to wait before merging it.



Sorry, but this is already merged.


It is definitely not clear that:

. The rfc was valid to begin with due to the short discussion time
. This BC is acceptable for 7.x

I think things like things can be prevented by following the 
relatively simple rfc process and having a more clear way to define 
what is acceptable as BC.




I think, the decision of the majority of voters, told that the BC break 
is minor and acceptable for 7.1.

The only mistake was in shorten discussion period.


I think the RMs should step in here.



Yeah, I suppose, RMs may have a right to take a decision and revert this.

Thanks. Dmitry.


Thanks,
Pierre

On Jun 16, 2016 1:12 PM, "Dmitry Stogov" > wrote:


Hi internals,


The RFC
https://wiki.php.net/rfc/too_few_args
was accepted by 39 against 11, and the corresponding patch was
merged into master.


Thanks. Dmitry.

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

[Pierre Joye]

On Jun 16, 2016 11:41 AM, "Joe Watkins"  wrote:
>
> Morning,
>
>> This would keep the "BC promise" intact instead of going back to
> cowboy php days.
>
>> Please don't let's make it harder to go from 7.0 to 7.1 than it was
> from 5.6 to 7.0.
>
>Can we reduce hyperbole to nil, please.
>
>Before work starts on PHP 8, we need to have something worth branching,
> just as we needed for 7, and 6.
>
>There is no sense in which the too_few_args vote was unfair, biased, or
> anything comparable to "the old days" (it wasn't committed without public
> consultation).
>
>The majority have decided that the *extremely minor* BC break is worth
> the tradeoff.

We have cases where our view on a problem and its impact was wrong, totally
wrong.

The rfc process allows veto even if accepted. I am very worried about how
things were done here. See my reply to Dmitry's approval mail for the
reasons.

Re: [PHP-DEV] [RFC] [Accepted] Replace "Missing argument" warning with "Too few arguments" exception

[Pierre Joye]

Hi Dmitry

I am sorry but I have to ask to wait before merging it.

It is definitely not clear that:

. The rfc was valid to begin with due to the short discussion time
. This BC is acceptable for 7.x

I think things like things can be prevented by following the relatively
simple rfc process and having a more clear way to define what is acceptable
as BC.

I think the RMs should step in here.

Thanks,
Pierre
On Jun 16, 2016 1:12 PM, "Dmitry Stogov"  wrote:

> Hi internals,
>
>
> The RFC https://wiki.php.net/rfc/too_few_args
> was accepted by 39 against 11, and the corresponding patch was merged into
> master.
>
>
> Thanks. Dmitry.
>
>

[PHP-DEV] [RFC] [Accepted] Replace "Missing argument" warning with "Too few arguments" exception

[Dmitry Stogov]

Hi internals,


The RFC https://wiki.php.net/rfc/too_few_args was 
accepted by 39 against 11, and the corresponding patch was merged into master.


Thanks. Dmitry.

[PHP-DEV] [RFC] [Accepted] Fix inconsistent behavior of $this variable

[Dmitry Stogov]

Hi internals,


The RFC https://wiki.php.net/rfc/this_var was accepted by 43 against 0, and the 
corresponding patch was merged into master.


Thanks. Dmitry.