This article was sponsored by NewRelic. Thank you for supporting the sponsors who make SitePoint possible!
A previous version of this article incorrectly stated that PHPNG is JIT. This is not the case, and the necessary amendments have been made. See bottom of article for more info.
Chaos in the old world! First HipHop, years ago, and no one bats an eye. Then suddenly, HHVM happens, introduces Hack, and all hell breaks loose – Facebook made a new PHP and broke/fixed everything (depending on who you ask). Furthermore, Zephir spawns and threatens with C-level compilation of all your PHP code, with full support for current PHP extensions (while Zephir is not intended to replace C or PHP, it does let you write near-PHP code and compile it to C, which lets you easily rewrite all your PHP apps to a format that can be close-sourced and compiled for speed and security). It’s mushroom growth time for alternative PHP runtimes, and HippyVM appears as well.
Amid the sea of changes, another splash was heard: PHPNG.
As introduced by Manuel Lemos, PHPNG is a new branch of PHP coming to a yet undetermined future version of PHP.
Wait, what?
This somewhat cheesily named (NG = new generation) and clumsily presented version of PHP is the core team’s attempt to optimize PHP drastically and allow JIT compilers in the future to push it even further. PHPNG is not a JIT, but an upgrade that allows the construction of a good JIT compiler later on. The PHPNG branch on its own does not include any JIT features.
PHPNG was presented by Dmitry Stogov in an internals newsgroup thread. Dmitry is responsible for performance and optimization at Zend, and mostly deals with the Zend Engine. The NG upgrade focuses on rewriting core parts of the Zend Engine to enable better memory allocation on PHP’s data types.
As quoted from Reddit:
NG exists because the experiments conducted by Zend in introducing a JIT failed in the real world because of the way the engine is currently designed, mostly because we allocate everything all the time. The NG patch changes the norm, so that we no longer by default allocate zvals, this increases performance and allowed for much tidier API’s.
As with any “Make PHP better” attempt, this one has its pros and cons.
Pros
Speed!
Faster execution means faster resource allocation, means faster request processing, means bigger request throughput. Initial results are promising (1, 2).
The performance still needs to be benchmarked against other alternative solutions, but 10-30% is nothing to scoff at.
Extensions!
Since this upgrade is being done on the official Zend Engine, not an alternative runtime, it pretty much guarantees compatibility with current extensions. One of the biggest reasons for people hesitating about a transfer to HHVM is the unavailability of essential extensions they’re used to (Phalcon, in my case). Personally, a faster engine for PHP that supports Phalcon would make me care significantly less about the upgrades Hack offers today.
So it guarantees extensions compatibility… wait. Does it? Uh oh.
Cons
Extensions!
Too good to be true.
Not all extensions are supported, some
tests are failing, and we also have more ideas for additional improvement.
In all fairness, NG is young. Far younger than anything we’ve ever really dealt with in the PHP world, and far more of a serious update – so it goes without saying that some compatibility issues are guaranteed. But I agree with Manuel here when he says this might be the pain point for most shared hosting providers when the time to upgrade comes.
Even though I’m quite vocal against shared hosting providers, I fully understand the problem this might pose. We’ve had a similar mess when we tried to make providers “Go PHP5”, and quite recently once more when they needed talking into more up to date versions of PHP, so getting them to make a big shift that has the potential to introduce BC breaks will be a daunting task.
This fear of change will cement the use of old PHP versions, in turn breeding more horribly unqualified PHP developers working on outdated code, completely oblivious to best practices and vulnerabilities. In short, we’re due for a replay of history. This might sound doomsday-ish, as some have pointed out, but being deeply involved in all circles of PHP and exposed to the lowest quality ones on a daily basis through a full inbox, I see where we are now and where we’re going. All is not black, however – solutions such as Heroku and DigitalOcean will let people run the most up to date and custom versions of PHP possible for prices as low as (or lower) than that of shared hosting providers.
My sincerest hope is that the core team will manage to iron the new Zend Engine out to such a degree that it retains backwards compatibility with ALL extensions, but giving warning pings on compilation to all extension developers who fail to adhere to NG’s regulations and best practices.
Internal Slowness
The core dev group is infamous for being slow to adapt to change. Modern features that existed for years in other languages were voted against in the past, only to be implemented years later.
Whether this is because the core dev team is simply without vision, like Anthony’s and Phil’s posts say, or because it’s too small and underfunded to make any major changes at a rapid pace is irrelevant – the internal slowness means we might never see NG out in the open and out of “alpha” status, much like the case was with the mythical PHP6.
This brings us to the last point.
Late to the Party… Again
Due to the inherent slowness often witnessed in the PHP core development group, by the time NG is implemented (if ever) all it will offer is a performance upgrade. By then, Hack with HHVM which is leaps and bounds above the standard PHP already will offer so many additional features, the race will be rigged and PHP won’t stand a chance.
Type hinting, available today in both Hack and Zephir, will have grown roots in those implementations. Multithreading, compilation, standalone web server – all features available today in alternative solutions, and all of them almost production ready. While the core dev group is working on some of those, and PHP will probably have IIS support way before HHVM (which is, apparently, important to some people), I personally still believe this isn’t nearly enough rapid progress from the official side of PHP.
Even if the core group does decide to vote “yes” on all these exotic features for which issues and demands exist, it’ll take them far too long to implement – and they’ll be late to the party by default, unless a paradigm shift is introduced and their entire way of working is turned around. Moving the source to GitHub was a good move, but it only scratched the surface.
That said, Rasmus himself supposedly said HHVM becoming PHP’s core engine in a few years isn’t that much of a Sci-Fi scenario.
Conclusion
Facebook-related ownership aside (which carries with itself plenty of negative connotations on its own), HHVM pushed the devs in the right direction by showing how such upgrades can be done. This drives innovation and forces those who have been comfortable in their throne for too long to get up, stretch their legs and see if they can still run. Facebook’s aggressive approach forced the PHP world to do a double-take and wonder about what’s going on, and soon enough it caught on.
Competition is awesome. Wherever this takes us next, I’m optimistic about it.
Article update May 28th, 2014
After an email exchange with Phil Sturgeon, and after reading the official statement, I have edited parts of the above text. In short, I classified PHPNG as a JIT, when it is clearly not that, but a mere performance upgrade that will allow the core group to develop a proper JIT compiler later on.
http://www.sitepoint.com/php-fights-hhvm-zephir-phpng/
https://news.ycombinator.com/item?id=8036707
No comments:
Post a Comment