Hacker News new | past | comments | ask | show | jobs | submit login
PHP 5.7 now nearly twice as fast as PHP 5.6 (ckon.wordpress.com)
127 points by colinramsay on July 15, 2014 | hide | past | favorite | 37 comments



Some clarification here about PHP versioning: the next minor version of will be PHP 5.6, which is still under development and has not yet been released. What is referred to as PHP 5.7 here is phpng, a proposed next major version of PHP. There's a lot of confusion about version naming of PHP, so it would be great if the author and HN could fix the title of this post (i.e. s/PHP 5.7/phpng/) as soon as possible to prevent spreading any further misinformation.


Yes, I found this out after I submitted the link. It's a little frustrating that someone (the blog post author) who is so interested and seemingly involved in this wasn't aware of this fact.


What seems to be a competition between HHVM and PHPNG performance optimizations is only going to be a net benefit for the community. A near 100% increase is definitely nothing to shake a stick at. I can only hope these optimizations continue in the future!


The author doesn't seem to say anything accurate. This isn't going to be 5.7. My understanding is that since there is something that is not this that is 6.x and that since this would be a major rev that this is more likely to be 7.x than 5.7

Then there is the magic "100% faster" but there isn't an explanation of what makes it faster, or what types of things will be faster. Is it faster for Computation? Faster for String manipulation? Is this mostly just memory access? Will Wordpress be faster? or things build on Zend? Or Drupal? Who will see this be faster?

I want to be excited. I don't really like PHP but I support a lot of it, and speed and stability would be great things to have improved, but I want a "why" that goes beyond, "The secret to this performance increase is that nearly 60% of cpu instructions have been “retired” by more efficient code"


Why not read the wiki and notice how Dmitry is trying different ideas for performance improvements? It started with memory optimizations but there are now many other little things like JIT regex.

It is all listed in the wiki and other ideas not attempted yet that might make it even faster.

Obviously not all code is going to be twice as fast, it is an average in a large program like wordpress. Some things more than twice as fast, some not so much.


> Will Wordpress be faster?

The content uses 1000 renderings of WP Front Page as to what it is measuring.

> what makes it faster?

The key aspect this post uses is cpu instructions and it drops by nearly 30%.

This definitely answers at least these two questions of yours.


We're going to need a HHVM 3.2 vs PHPNG benchmark showdown.

PHPNG is far easier to install/configure though.


Just quoting ircmaxellAnthony who is kind of a PHP authority

> "Calling this 5.7 is bad."


but its not PHP 5.7


There is some confusion over the version naming because the version file inside phpng says 5.7.0 - but that might just be a placeholder:

https://github.com/php/php-src/blob/phpng/main/php_version.h

     #define PHP_VERSION "5.7.0-dev"


Whether it's 5.7 or 6.0 (or as one suggestion pegged it, 7.0), it's still phpng :)


Yes, but the title of this article says "5.7" which implies something different from "phpng"


But it's not. Its referring to phpng as 5.7.


Until an official statement yours is wrong in the same way like the title.


Until its been accepted (it hasnt) it shouldn't be called any version number.

So my comment is correct, the title is not.


I get down-voted for stating a fact, welcome to hacker news.


While you shouldn't have been downvoted, you also shouldn't complain about it. "Resist complaining about being downmodded. It never does any good, and it makes boring reading. " ~ https://news.ycombinator.com/newsguidelines.html

That said, while both you and ircmaxell (who is a commenter on the article's page and very involved in the PHP community) can be a bit terse when making assertions it doesn't make you wrong. I can't possibly see this being labeled 5.x and the 6.x major version number is inseparably bound to the 5-year-old vaporware.


If we don't complain about it, nothing will change and the nonsense will continue.

Hacker News used to be a great place for open discussion. Now, anything even slightly against the silicon valley hive-mind is downvoted.

Any time PHP comes up, there are tons of garbage comments stating how terrible of a language it is. This is not constructive in any way and adds nothing to the discussion. No downvotes in sight. Why? Because the downvoting is only used as a tool to silence opposing viewpoints. It has almost nothing to do with keeping out the trolls.

I guess I shouldn't be surprised. It's almost a perfect mirror of our society today. Just look at all of the people getting fired and having their careers ruined for merely having opposing viewpoints to the special interest groups in the US.


> If we don't complain about it, nothing will change and the nonsense will continue.

It corrected itself, and the post is fine now. Complaining about down votes, however, should be discouraged.

> Hacker News used to be a great place for open discussion. Now, anything even slightly against the silicon valley hive-mind is downvoted.

I've been bearing that since I joined.

> Because the downvoting is only used as a tool to silence opposing viewpoints.

That's not true.

Coming into a thread still going on, you're just getting a snapshot. Yes, there will be up votes and down votes, but I find that generally things get corrected in the end.

However, contributing to the problem by complaining about down votes doesn't help matters. It makes them worse.

What's interesting is that the comment getting down voted now: "I get down-voted for stating a fact, welcome to hacker news.", is false in every way.


Programming languages are tools, not religions. Calling PHP terrible is not an "opposing viewpoint", it's stating facts. It's not garbage either: if these comments manage to help people steer clear of PHP in favour of stronger tools, they have served their good purpose.


The increasing douchebaggery of this site seems to be unwelcoming to even comment anymore.


My point exactly.


PHP-5.6 isn't even out yet.


So?


"The secret to this performance increase is that nearly 60% of cpu instructions have been “retired” by more efficient code:"

Well, where else was the speed-up going to come from?

"You can't actually make computers run faster, you can only make them do less."

-- Unknown (My gratitude if anyone does know the source of this quote)

Clearly, "doing less" does include things like "(re-)fetching a bunch of bits into the cache", but "executing fewer instructions" is definitely one of the most obvious places to start.


To be far you can get speed ups like this going from very a very cache unfriendly instruction stream to a very cache aligned one or my changing your instruction mix while maintaining a similar number of total operations ; so this statement is not as "Captain Obvious" as it looks at first glance. Of course, not running extra instructions is better :)


That quote might be by RiderOfGiraffes:

https://news.ycombinator.com/item?id=1626405


Similarly,

"It's hardware that makes a machine fast. It's software that makes a fast machine slow."

-Craig Bruce


That reminds of this quote from Mike Haertel:

The key to making programs fast is to make them do practically nothing. ;-)


Sure you can, it's called overclocking.


Parallel processing is doing less?


Unfortunately, judging from my own (very limited) speed tests, that result simply means that it is en par with PHP 5.5.

PHP 5.6 is not only not finished yet - it is, in my experience, also the worst performing version you could choose. Not sure that's a good idea.


Perhaps you are configuring them differently.

I have a test box with all recent 5.x versions installed.

1000 WP front pages, identical php build configuration:

     5.4    28.081s, 28.673s, 29.458s, 28.017s

     5.5    26.402s, 26.448s, 26.522s, 26.523s

     5.6    25.774s, 25.643s, 25.752s, 25.670s

      NG    15.083s, 15.100s, 15.052s, 15.066s


Common mistakes: Testing with xdebug enabled in one version or testing with opcache enabled in only one version.


I was testing with:

PHP 5.6.0beta4 (cli) (built: Jun 12 2014 14:13:53)

Zend Engine v2.6.0-dev, Copyright (c) 1998-2014 Zend Technologies

with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

vs.

PHP 5.5.13 (cli) (built: Jun 12 2014 13:54:54)

Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies

with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

...but, as I said - this is with very limited testing, basically just on Travis (which goes up and down in speed all day, but the difference between versions is pretty steady).


Note RC3 is about to ship so maybe try that.

Is xdebug load neutral? Maybe you need to skip loading that during testing, you wouldn't use it during production?


The "limit" of my test is that it's sort of a worst-case scenario - Travis does have a couple of things set up that you may not find in the wild, but the entire purpose is to get speed ratings on a purposefully crappy system.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: