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

[lp_benchmark_robot]

Results for project PHP master, build date 2017-08-22 19:23:33-07:00
commit: 3cb6407
previous commit:1287c20
revision date:  2017-08-22 16:55:03+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.13% -0.98%  3.83%  
  9.13%
:-|   Drupal 7.36 cgi -T1  0.19% -0.26%  3.72%  
  5.41%
:-|   MediaWiki 1.23.9 cgi -T5000  0.08% -0.60%  3.93%  
  4.39%
:-|   bench.php cgi -T100  0.05% -0.33% 45.27%  
 -0.37%
:-|  micro_bench.php cgi -T10  0.01% -0.78% 28.46%  
  3.28%
:-(  mandelbrot.php cgi -T100  0.01% -4.59% 42.75%  
  4.66%
---

* 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-08-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

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

[Adam Baratz]

>
> That change was implemented in the SQLite3 extension without a RFC, so I'm
> quite confused here.
>

My literal reading of the contribution guide[1] is that new features should
be preceded by an RFC, though there are certainly cases where this doesn't
happen. I don't have a clear enough understanding of this community to say
when RFCs can be skipped. I'm not sure who the authority would be. The
release manager for the next minor rev? Anyone with commit privileges?

I kinda feel like it's a weird thing to submit an RFC that would basically
> ask the question "should pdo_sqlite only implement a subset of SQLite",
> because well it is most likely that if you are using a DB driver with PDO
> you most likely want to be able to access that DB features, no?
>
> Or are you saying that we should have a vote on whether the implementation
> should follow what is already existing in PDO or should propose something
> new instead? Because I frankly don't know what would be a better idea than
> driver-specific methods and I don't know enough C/have enough time to do
> anything else, so I won't submit any proposition that I won't be able to do
> myself.
>

Only speaking for myself: I'd just want the RFC to act as a sanity check
that the method you're adding has the right signature and it's being
implemented consistently with similar methods. I don't like the design
pattern either, but it's not like you're introducing it. It's better for
PDO to be feature complete than to have a perfect architecture. A tool
missing functionality will be less desirable to use. I'd be more concerned
about the consequences of that state. Whoever wants to figure out the right
way to support extension-specific methods would have to figure out how to
deprecate the existing methods. Adding one wouldn't really change the scope
of this problem, which isn't intractable in the greater scheme of things.

Thanks,
Adam

---
[1] https://github.com/php/php-src/blob/master/CONTRIBUTING.md

Re: [PHP-DEV] PHP 7.1.0 to 7.2.0beta2 mt_rand() modulo bias bug

[Solar Designer]

On Thu, Aug 17, 2017 at 03:18:30PM +0200, Solar Designer wrote:
> On Thu, Aug 17, 2017 at 12:57:56AM +0200, Nikita Popov wrote:
> > On Thu, Aug 17, 2017 at 12:02 AM, Solar Designer  wrote:
> > > One difference I didn't notice at first: the currently committed code
> > > does only one php_mt_rand() call per loop iteration when it's skipping
> > > "numbers over the limit", even in the 64-bit case (thus, it replaces 32
> > > bits of the value at a time).  Your 64-bit version (and my revision of
> > > it) does two calls per iteration (replacing the whole number).
> > >
> > > Arguably, the currently committed code is smarter and more efficient in
> > > that respect, whereas yours is cleaner.  Regardless, it's an extra
> > > change that will affect the generated random numbers in some cases where
> > > we could avoid making that change (it's not fixing any bug).
> > >
> > > I think it's preferable not to unnecessarily change what numbers are
> > > generated.
> 
> > Good point. However, I think that this optimization is not actually
> > correct. For example, let's take umax = 0x1__0001, which is the
> > smallest value for which this codepath is taken. In this case limit would
> > be 0x___fffe, so we only resample if the value is exactly
> > 0x___. So if the resampling codepath is taken in this case,
> > and we only generate one new 32-bit value, the top word of the result will
> > be fixed to 0x_. (A very small bias in this case, but there's
> > probably more significant cases.)
> 
> Great point.  More generally, we can't reuse the same random number for
> decision-making (to skip it) and as part of the next (not so) random
> number, without introducing bias.  So we shouldn't, and we should in
> fact move away from the old "smarter" behavior as a bug fix.  Thank you!

So I guess both the bug I reported and this one Nikita found are going
to get fixed soon?  For 7.2.0 maybe?

Meanwhile, I released php_mt_seed 4.0 yesterday with support for latest
PHP's mt_rand(), as well as with support for PHP 5.2.0 and below (as it
happens, all the way to 3.0.7, although that's overkill).  Near the end
of its documentation, I included a lengthy section entitled "PHP version
curiosities", which I include below in this e-mail in case any of this
is useful for PHP's own documentation.  It starts from PHP 3.0.6, but
then actually spends half of the text on PHP 7.1.0+.  Here we go:

---
While php_mt_seed supports 3 major revisions of PHP's mt_rand()
algorithm and that sort of covers PHP 3.0.7 through 7.1.0+ (up to the
latest as of this writing and probably beyond), the reality is somewhat
trickier than that.  From older versions to newer:

As a mere historical curiosity, php_mt_seed is in fact able to crack
seeds of PHP 3.0.6, which is the very first version that introduced
mt_rand(), but only as long as no range was passed into mt_rand().  That
version had broken support for ranges, and indeed there's no point in
supporting that short-lived breakage in php_mt_seed now.  With this
detail, php_mt_seed has some support for all mt_rand() capable versions
of PHP released so far.

Then there's PHP 3.0.7 through 5.2.0, where Mersenne Twister's state
initialization is with multiples of 69069.  This enables our stateless
implementation to quickly jump to the state array element needed to
compute the first mt_rand() output by using a precomputed value for
69069 raised to the power 396 (mod 2**32), which is MT's M-1.  Another
curiosity of those versions, which we take advantage of too, is that
they treat adjacent even and odd seeds the same, so the effective seed
space is 31-bit.

PHP 3.0.6 to 4.1.2 used a default seed of 4357 (and thus also 4356) if
mt_srand() was not called.  PHP 4.2.0 changed that to automatic seeding
using system time and PHP process ID (still predictable and now also
leaky, but no longer a constant), but there was "Bug #25007 rand &
mt_rand seed RNG every call" until 4.3.3, which presumably affected how
cracked seeds could (not) be used.

PHP 5.2.1 changed MT state initialization to MT authors' new recommended
algorithm, which is no longer linear so we have to compute the first 397
state elements (out of 624) even though in the simplest case we only
need (and only store) the first and last one of those (or we could use a
time-memory trade-off, which we currently don't).

PHP 5.2.1 also introduced a bug into its implementation of MT (use of a
wrong variable, whereas pre-5.2.1 code was correct in that respect).
This bug lets us skip a few operations for every other seed, which we
do, although this optimization is so minor that we could as well not
bother.  PHP 7.1.0 fixed this bug (reverting to pre-5.2.1 code in that
respect, so we use the same logic for pre-5.2.1 and 7.1.0+ there).

In PHP versions from 3.0.7 to 7.0.x, if mt_rand() was called with its
optional output range specified, a 31-bit (0 to 2147483647) MT PRNG
output was scaled to that range using 

Re: [PHP-DEV] GD vs Imagick

[Christoph M. Becker]

On 23.08.2017 at 14:42, Rasmus Schultz wrote:

> The libvips module does in deed look interesting. I suppose this would have
> all the same problems though? Lots of dependencies.
> 
> So GD wins perhaps mostly because it's small and has fewer dependencies.

I'm not sure about that.  If GD is to be built with the full feature
set, it needs libgpng, libjpeg, libwebp, libxpm, libtiff, libfreetype
and libfontconfig.  Basically, only the GIF and BMP stuff are
implemented by libgd itself.

> Ideally, I think that GD should be fixed, since it's the default (by which
> I mean, it's the only option on a standard PHP install) so that libraries
> like Intervention Image can deliver predictable results.

I don't think that anybody disagrees with this, but it's simply a matter
of man power.  Also note, that storing the color profiles when reading
an image would cause an ABI break, so that can't happen in 2.2.x, but
would have to wait for 2.3, which might be far away.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] GD vs Imagick

[Thomas Hruska]

On 8/23/2017 5:42 AM, Rasmus Schultz wrote:

I'm not a C developer though, so I can't help with that.


The world's core software runs on C.  PHP is also written in C.  You 
can't develop extensions for PHP unless you know C.  Developing userland 
applications in PHP is a lot easier when you know how to deep dive into 
PHP's source code because you can know precisely what each option will 
do even if the public documentation is a bit sparse in places.  Those 
are several reasons to start learning C even if you don't use it in your 
day-to-day development efforts.  A whole world of possibilities opens up 
when you learn C and you'll be a more well-rounded software developer too.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

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

Re: [PHP-DEV] GD vs Imagick

[Rasmus Schultz]

Thank you all for considering the subject and contributing your thoughts.

I understand why Imagick is not attractive as a standard module (even
according to the maintainer) since we can't feasible bundle all it's
dependencies, so I suppose that's a no-go.

The libvips module does in deed look interesting. I suppose this would have
all the same problems though? Lots of dependencies.

So GD wins perhaps mostly because it's small and has fewer dependencies.

Color profiles in my experience are pretty common though - and currently
(silently) leads to mangled images with GD.

I've seen a work-around, as somebody mentioned, which involves parsing the
binary contents of JPEG files, extracting the color profile and injecting
it into a JPEG file after GD has saved it - this is (A) horrible in terms
of memory and CPU usage, and (B) not what most users are going to want in
the first place; you most likely want color profiles moved, which is better
in terms of browser compatibility and performance when delivering images
over the web. So this is not a good work-around.

I wanted to contribute to Intervention Image - a library that abstracts GD
and Imagick behind a common API, but it turns out, this can't be
implemented with GD in PHP, except of course resorting to approaches like
pixel-by-pixel manipulation, for which PHP is totally unsuitable.

Ideally, I think that GD should be fixed, since it's the default (by which
I mean, it's the only option on a standard PHP install) so that libraries
like Intervention Image can deliver predictable results.

I'm not a C developer though, so I can't help with that.


On Thu, Aug 17, 2017 at 7:03 AM, Pierre Joye  wrote:

> hi Rasmus,
>
> On Tue, Aug 15, 2017 at 5:52 PM, Rasmus Schultz 
> wrote:
> > The following GD issue is all-too common:
> >
> > https://stackoverflow.com/questions/5773032/how-to-stop-
> gd2-from-washing-away-the-colors-upon-resizing-images
> >
> > Basically anyone who's ever accepted uploaded images and resized or
> > converted them, has bumped into this.
> >
> > Only Imagick makes it possible to work around this issue, it's not
> possible
> > with GD, at all - and the internal behavior of GD is arguably "wrong", as
> > the visible output of simply opening and saving a JPEG image with GD is
> > mangled with washed-out colors.
> >
> > I am starting to wonder why GD is the default in PHP?
> >
> > It's a pretty outdated library with a clunky API - we have Imagick with a
> > much more concise API and a ton more useful features.
>
> I disagree here, as old functions are old fashioned, new ones are easy
> to understand and to use. Not OO, but that's a little details (contrib
> welcome). And I disagree with outdated as well. It is focused on
> easiness and most common usages. More features make it depending on
> the requests or available time to actually add them. Performance wise
> it is also similar to similar actions.
>
> > Why is the less-capable image library the default on the PHP platform?
> Why
> > not Imagick?
>
> Imagick is good, but it is a huge library, by its size, features, code
> base (external) and complexity. I would never ever recommend to have
> it bundled or even less by default.
>
> In any cases, both libraries (or the bindings) welcome contributors,
> you are more than welcome too :)
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

[Lester Caine]

On 23/08/17 06:15, BohwaZ/PHP wrote:
> I'm not gonna create another way of having driver-specific features that
> wouldn't make sense in relation to existing methods, and I don't have
> time to rewrite a significant part of PDO that would cause a major
> BC-break.

The original intention of PDO was that it did not matter just what
underlying database you were using, anything written for one would
simply work with any other. All of the driver specific extensions make a
mockery of that, and in many cases today PDO will only work with the
database it was programmed for ... so why use PDO at all in that
instance? For example a BLOB improvement to PDO should work
transparently across all databases that support blobs ... and error when
blobs are not available.

-- 
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] Contravariance and the "empty type"

[Michał Brzuchalski]

Hi Andreas,

2017-08-22 21:11 GMT+02:00 Andreas Hennings :

> On Tue, Aug 22, 2017 at 10:39 AM, Nikita Popov 
> wrote:
> > On Tue, Aug 22, 2017 at 4:27 AM, Andreas Hennings 
> > wrote:
> >>
> >> Hello list,
> >> for a while I had this thought about contravariance and an "empty type".
> >> I don't expect too much of it, for now I just want to share the idea.
> >> Maybe this concept even exists somewhere in a different language, and
> >> I am not aware of it.
> >>
> >> I think it has some overlap with generics,
> >> https://wiki.php.net/rfc/generics.
> >>
> >> 
> >>
> >> I think I am not the first one to suggest allowing contravariance for
> >> method parameters.
> >> E.g. here, "PHP RFC: Parameter Type Widening"
> >> https://wiki.php.net/rfc/parameter-no-type-variance
> >>
> >> From this RFC:
> >> > Unfortunately “true” contravariance for class types isn't part of this
> >> > RFC, as implementing that is far more difficult, and would require
> >> > additional rules about autoloading and/or class compilation, which
> might
> >> > only be acceptable at a major release.
> >>
> >> For anyone not familiar with the term:
> >>
> >> interface I {
> >>   function foo(J $arg);
> >> }
> >>
> >> interface J extends I {
> >>   function foo(I $arg);
> >> }
> >>
> >> So: While return types in a child method should be either the same or
> >> more narrow, the parameter types should be either the same or more
> >> permissive.
> >> Without this it would break Liskov substitution.
> >>
> >> ---
> >>
> >> Now for my actual proposal: The "empty type".
> >> We can think of a type (class/interface or primitive) as a set or a
> >> constraint on the kind of values that it allows.
> >> There is a special type, "mixed", which allows all values. We could
> >> also think of it as the union of all types.
> >>
> >> A natural extension of this concept, on the other end, would be a type
> >> "nothing" or "empty", which would allow no values at all.
> >> We could think of this as the intersection of all types.
> >> In fact it is already sufficient to intersect just two distinct
> >> primitive types to get this empty type:
> >> "All values that are at the same time string and integer" clearly is
> >> an empty type.
> >>
> >> How would this ever be useful?
> >> If we write a base class or interface for a category of interfaces
> >> that have a similar signature.
> >>
> >> interface Fruit {..}
> >> interface Apple extends Fruit {..}
> >> interface Banana extends Fruit {..}
> >>
> >> interface AbstractFruitEater {
> >>   function eat(EMPTY_TYPE $fruit);
> >> }
> >>
> >> interface BananaEater extends AbstractFoodEater {
> >>   function eat(Banana $banana);
> >> }
> >>
> >> interface AppleEater extends AbstractFoodEater {
> >>   function eat(Apple $apple);
> >> }
> >>
> >> One could imagine a component that has a list of AbstractFruitEater
> >> objects, and chooses one that is suitable for the given fruit, using
> >> instanceof.
> >> I think the correct term is "chain of responsibility".
> >>
> >> function eatApple(array $fruitEaters, Apple $apple) {
> >>   foreach ($fruitEaters as $eater) {
> >> if ($eater instanceof AppleEater) {
> >>   $eater->eat($apple);
> >>   break;
> >> }
> >>   }
> >> }
> >>
> >> 
> >>
> >> We can go one step further.
> >>
> >> The natural parameter type to use for param $fruit in
> >> AbstractFruitEater::foo() would not be the global EMPTY_TYPE, but
> >> something more specific:
> >> The projected intersection of all real and hypothetical children of
> >> interface Fruit.
> >> Obviously this does not and cannot exist as a class or interface.
> >>
> >> Practically, for the values it allows, this is the same as the global
> >> EMPTY_TYPE.
> >> But unlike the EMPTY_TYPE, this would poses a restriction on the
> >> parameter type in child interfaces.
> >>
> >> What would be the syntax / notation for such a projected hypothetical
> >> subtype?
> >> I don't know. Let's say INTERSECT_CHILDREN
> >>
> >> So, would the following work?
> >>
> >> interface Food {..}
> >> interface Fruit extends Food {..}
> >> interface Banana extends Fruit {..}
> >>
> >> interface AbstractFoodEater {
> >>   function eat(INTERSECT_CHILDREN $food);
> >> }
> >>
> >> interface AbstractFruitEater extends AbstractFoodEater {
> >>   function eat(INTERSECT_CHILDREN $fruit);
> >> }
> >>
> >> interface BananaEater extends AbstractFruitEater {
> >>   function eat(Banana $banana);
> >> }
> >>
> >> I'm not sure.
> >> Liskov would not care. Both AbstractFoodEater and AbstractFruitEater
> >> are useless on their own.
> >> Maybe there are other logical conflicts which I don't see.
> >>
> >>
> >> --
> >>
> >> Obviously with generics this base interface would no longer be relevant.
> >> https://wiki.php.net/rfc/generics
> >>
> >> interface FruitEater {
> >>   function eat(FruitType $fruit);
> >> }
> >>
> >> // This is not really