[PHP-DEV] BAD Benchmark Results for PHP Master 2017-05-22

[lp_benchmark_robot]

Results for project PHP master, build date 2017-05-22 19:24:08-07:00
commit: 293d990
previous commit:26a6d20
revision date:  2017-05-22 23:23:12+03: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.28% -0.25%  0.03%  
  8.74%
:-|   Drupal 7.36 cgi -T1  0.14%  0.55% -0.39%  
  5.28%
:-|   MediaWiki 1.23.9 cgi -T5000  0.07% -0.19%  1.35%  
  4.47%
:-|   bench.php cgi -T100  0.04% -0.51% 45.89%  
  4.36%
:-(  micro_bench.php cgi -T10  0.02% -1.05% 19.46%  
  3.62%
:-|  mandelbrot.php cgi -T100  0.03% -0.83% 43.90%  
  4.47%
---

* 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-2017-05-22/

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

[PHP-DEV] [RFC] [Discussion] UUID

[Fleshgrinder]

Hey internals!

I haven't written the RFC yet, but the implementation is already done. I
think that this is enough to start the discussion, since the concept of
UUIDs should be well known to most people.

https://github.com/php/php-src/pull/2535

The best starting point, also for non-C people, is the stubs directory
where I created PHP files with full documentation:

https://github.com/Fleshgrinder/php-src/tree/rfc/uuid/ext/standard/stubs

I am also planning on providing PHP 5 and 7 polyfills, so that people
can prepare their code long before the feature is actually landing in
userland.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Parameter type widening RFC

[Levi Morrison]

On Tue, May 23, 2017 at 1:25 PM, Rasmus Schultz  wrote:
>
> I feel like this feature takes a pretty dangerous shortcut by simply
> removing a constraint check that we used to have - in favor of supporting a
> few rare cases, we removed a guarantee that interfaces and the
> implements-keyword has always provided.
>
> Those rare cases could have been supported in a safe manner by introducing
> a "mixed" or "any" type, which would have made the use of this feature
> explicit - which would have removed the risk of accidental omission of
> type-hints in the majority of cases.
>

This was my opinion at voting time which is why i voted against the RFC. It
passed 24 to 5 so it's just something we'll have to live with for now.

Re: [PHP-DEV] Parameter type widening RFC

[Niklas Keller]

Hi Rasmus,


> This parameter type widening RFC, I didn't know about, but I have a remark.
>
> The feature, as implemented, will allow accidental omission of type-hints,
> will it not?
>

Yes, correct.


> Previously, the implements keyword guaranteed a correctly type-hinted
> implementation - it's now possible to (purposefully, obviously, in certain
> rare cases) omit type-hints by accident, making the implements keyword much
> less (or not any) of a guarantee that the interface is implemented
> correctly.
>

The interface will just work correctly, what's the actual problem you're
seeing?


> The addition of an explicit "mixed" or "any" pseudo-type would have made
> this possible, without losing the guarantee that the implements keyword
> used to provide - that is, it would have been possible to have this feature
> for the few cases where it's useful, without affecting safety in the
> majority of other cases where it's not.
>
> I feel like this feature takes a pretty dangerous shortcut by simply
> removing a constraint check that we used to have - in favor of supporting a
> few rare cases, we removed a guarantee that interfaces and the
> implements-keyword has always provided.
>
> Those rare cases could have been supported in a safe manner by introducing
> a "mixed" or "any" type, which would have made the use of this feature
> explicit - which would have removed the risk of accidental omission of
> type-hints in the majority of cases.
>

Unfortunately, that doesn't work for the second (maybe even primary) use
case of the RFC: Adding types to a class isn't a BC break anymore with the
RFC, as child classes will just widen the type and need explicit checks as
before. Without the RFC or with a version with "mixed" or "any", method
signatures will be incompatible again and thus be a BC break when adding
types to the base class.

"mixed" has been mentioned in the original discussion, but there was not a
lot of interest and mostly explicit disinterest.


> The RFC page doesn't link to any discussion, and the Github thread was shut
> down after some negative remarks.
>
> I didn't see a discussion or a vote here on internals - did I miss
> something? Where or how did this get discussed and passed? Are these
> discussions happening somewhere else besides internals now?


 - Original discussion: https://externals.io/thread/505
 - Vote announcement: https://externals.io/thread/613
 - Vote resumption after internals having issues:
https://externals.io/thread/619

Regards, Niklas

Re: [PHP-DEV] Parameter type widening RFC

[Fleshgrinder]

On 5/23/2017 9:51 PM, Nikita Popov wrote:
> One of the primary motivations behind this RFC is to allow the addition of
> typehints (for example in library code) without introducing a backwards
> compatibility break for any code implementing or extending your
> interface/class. Requiring an explicit "mixed" or "any" type would not
> allow this. I think this is 95% of the reason for this RFC, so without it,
> the change itself is probably not worthwhile.
> 

Yeah, I remember that and it is actually one of the very first sentences
in the RFC:

> Implementing this RFC would allow libraries to be upgraded to use
> type declarations in their method signatures. Currently adding types
> to a method of a class in a library would break any code that extends
> that class.
>
> --- https://wiki.php.net/rfc/parameter-no-type-variance

This was/is a great feature for library developers. We should probably
add Rasmus' concern to the list of things that can be added in PHP 8.
Another possible approach here could be to enforce an explicit "mixed"
if "strict_types" are active for the declaring class.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Parameter type widening RFC

[Nikita Popov]

On Tue, May 23, 2017 at 9:25 PM, Rasmus Schultz  wrote:

> This parameter type widening RFC, I didn't know about, but I have a remark.
>
> The feature, as implemented, will allow accidental omission of type-hints,
> will it not?
>
> Previously, the implements keyword guaranteed a correctly type-hinted
> implementation - it's now possible to (purposefully, obviously, in certain
> rare cases) omit type-hints by accident, making the implements keyword much
> less (or not any) of a guarantee that the interface is implemented
> correctly.
>
> The addition of an explicit "mixed" or "any" pseudo-type would have made
> this possible, without losing the guarantee that the implements keyword
> used to provide - that is, it would have been possible to have this feature
> for the few cases where it's useful, without affecting safety in the
> majority of other cases where it's not.
>
> I feel like this feature takes a pretty dangerous shortcut by simply
> removing a constraint check that we used to have - in favor of supporting a
> few rare cases, we removed a guarantee that interfaces and the
> implements-keyword has always provided.
>
> Those rare cases could have been supported in a safe manner by introducing
> a "mixed" or "any" type, which would have made the use of this feature
> explicit - which would have removed the risk of accidental omission of
> type-hints in the majority of cases.
>

One of the primary motivations behind this RFC is to allow the addition of
typehints (for example in library code) without introducing a backwards
compatibility break for any code implementing or extending your
interface/class. Requiring an explicit "mixed" or "any" type would not
allow this. I think this is 95% of the reason for this RFC, so without it,
the change itself is probably not worthwhile.


> The RFC page doesn't link to any discussion, and the Github thread was shut
> down after some negative remarks.



> I didn't see a discussion or a vote here on internals - did I miss
> something? Where or how did this get discussed and passed? Are these
> discussions happening somewhere else besides internals now?
>

The RFC was discussed in http://markmail.org/message/2oydyyl45v4korau. You
participated in that discussion.

The vote started in http://markmail.org/message/jgn4hwcgeezzk22w.

Both of those were found by searching for the literal RFC name.

Nikita

Re: [PHP-DEV] Parameter type widening RFC

[Fleshgrinder]

On 5/23/2017 9:25 PM, Rasmus Schultz wrote:
> This parameter type widening RFC, I didn't know about, but I have a remark.
> 
> The feature, as implemented, will allow accidental omission of type-hints,
> will it not?
> 
> Previously, the implements keyword guaranteed a correctly type-hinted
> implementation - it's now possible to (purposefully, obviously, in certain
> rare cases) omit type-hints by accident, making the implements keyword much
> less (or not any) of a guarantee that the interface is implemented
> correctly.
> 
> The addition of an explicit "mixed" or "any" pseudo-type would have made
> this possible, without losing the guarantee that the implements keyword
> used to provide - that is, it would have been possible to have this feature
> for the few cases where it's useful, without affecting safety in the
> majority of other cases where it's not.
> 
> I feel like this feature takes a pretty dangerous shortcut by simply
> removing a constraint check that we used to have - in favor of supporting a
> few rare cases, we removed a guarantee that interfaces and the
> implements-keyword has always provided.
> 
> Those rare cases could have been supported in a safe manner by introducing
> a "mixed" or "any" type, which would have made the use of this feature
> explicit - which would have removed the risk of accidental omission of
> type-hints in the majority of cases.
> 
> The RFC page doesn't link to any discussion, and the Github thread was shut
> down after some negative remarks.
> 
> I didn't see a discussion or a vote here on internals - did I miss
> something? Where or how did this get discussed and passed? Are these
> discussions happening somewhere else besides internals now?
> 

Hey Rasmus!

- Discussion: https://marc.info/?t=14797213621=1=2

I also had a look at the GitHub discussion, and I think that the things
that were written there have nothing to do with your concern. The people
commenting there simply did not understand LSP.

That being said, your remark is actually more than legit and I have to
agree that this is indeed just crying out for static analysis tools to
add more warnings to code.

I would very much love to see "any", but introducing yet another keyword
is imho not a good idea. We have already an extremely mixed up
terminology, hence, "mixed" would do and match the existing grammar of
PHP nicely.

There is time left for PHP 7.2 (20. July I think), maybe this is fixable
before that? I guess this will require an RFC too though.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Parameter type widening RFC

[Rasmus Schultz]

This parameter type widening RFC, I didn't know about, but I have a remark.

The feature, as implemented, will allow accidental omission of type-hints,
will it not?

Previously, the implements keyword guaranteed a correctly type-hinted
implementation - it's now possible to (purposefully, obviously, in certain
rare cases) omit type-hints by accident, making the implements keyword much
less (or not any) of a guarantee that the interface is implemented
correctly.

The addition of an explicit "mixed" or "any" pseudo-type would have made
this possible, without losing the guarantee that the implements keyword
used to provide - that is, it would have been possible to have this feature
for the few cases where it's useful, without affecting safety in the
majority of other cases where it's not.

I feel like this feature takes a pretty dangerous shortcut by simply
removing a constraint check that we used to have - in favor of supporting a
few rare cases, we removed a guarantee that interfaces and the
implements-keyword has always provided.

Those rare cases could have been supported in a safe manner by introducing
a "mixed" or "any" type, which would have made the use of this feature
explicit - which would have removed the risk of accidental omission of
type-hints in the majority of cases.

The RFC page doesn't link to any discussion, and the Github thread was shut
down after some negative remarks.

I didn't see a discussion or a vote here on internals - did I miss
something? Where or how did this get discussed and passed? Are these
discussions happening somewhere else besides internals now?