PHP Fights HHVM and Zephir with PHPNG

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.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Peter Kokot

    I always sort of felt that PHP will bring better solution than Facebook currently tries with HHVM and is making a big confusion with HackLang. Though we must be honest Facebook engineers contribute to PHP big time as well. Future for PHP users holds great cookies anyway in any final case when those engines will be used in production :D

  • http://heera.it/ Sheikh Heera

    I think Hack is awesome but not reliable since it’s FaceBook and I don’t trust them, so don’t want to lose my root for greed and PHP is getting better and JIT and Type hinting are only two features that I’m counting that PHP doesn’t provide but still I’ll wait until there is a bigger community and available resources (frameworks, libraries and support). Hack has 50 % chances, IMO.

    • David

      Don’t confuse the fruits of their technology stack with their poor reputation for privacy, or their product featurs.

      There’s nothing untrustworthy with Facebook’s technology implementations. They’ve done top shelf stuff and they don’t flit from solution to solution. Each part of their stack is a major investment for them.

      • http://www.bitfalls.com/ Bruno Skvorc

        Quite right. Sometimes the technology a group makes has nothing to do in quality or attitude with their actual product. Twitter Bootstrap is another example – it’s a great framework, and yet if you look at Twitter itself it’s a mess and a horror of slow loading and often crashing interface elements. Facebook made a plethora of interface libraries and novel approaches to building a UI, and their UI on facebook.com falls apart and bugs out regularly.
        Facebook can and probably will do great things with Hack.

      • http://heera.it/ Sheikh Heera

        I’ll have no problem with FB I think still it’s not the right time to switch. Let’s wait and see if it gains enough reps and if a community grow for it with available resources and support. BTW, I tried it on Heroku and really liked it.

  • Dante

    Bruno sjedi 5 :)

  • http://r.je Tom Butler

    I’m a little uneasy with so many forks of PHP with their own syntax. This is slowly causing fragmentation the result of which will be PHP losing one if it’s biggest strengths: portability. We’ll end up with a HHVM WordPress fork that won’t run on PHP, a Zephir fork of MediaWiki that won’t run on HHVM or PHP and a terrible amount of duplication of effort by developers who want to make portable applications.

    If they all run the same code at different speeds, fine, but that isn’t what’s really happening here as noted with the type hinting example above.

  • CTN

    It’s all good. Once all these new tricks and hacks shake out, we will have a better PHP. Ultimately, Facebook might decide to go with its own fork of PHP and develop it solely to meet its own needs, which could also turn out to be the needs of many others. Maybe Facebook should just buy PHP?

  • Yaron

    I can’t see a good reason for Facebook not to work with Zend on the best overall solution
    After all, until the recent migration to Hack, Facebook was written using Zend’s PHP

    This way they will appear as contributers to the community like they’re trying to present themselves while still getting a very clear benefit from their “donation” (couple of millions per year in servers expenditure)

    I certainly don’t trust Facebook to do what best for the community (eventually everything they do ends up in their bank account numbers), while the pace of Zend’s development and innovation is awful ( especially comparing to Facebook)

    Bottom line:
    Someone should take Mark, Zeev and Andy to lunch

    • http://www.bitfalls.com/ Bruno Skvorc

      They do work together a lot already. It’s just that the development speed of the regular PHP is too slow for Facebook’s needs.

    • http://www.jbwebware.com/home/ Burnsy

      @Yaron: That’s not true. Facebook started out using the PHP/Zend Engine, but had to use a lot of C++ until they created the HipHop Compiler, which compiled PHP to C++/Executables. They then release HHVM, and later included Hack to run on HHVM.

      It’s been quite a long time since Facebook has used PHP exclusively.

  • http://r.je Tom Butler

    Of course, but someone will fork wordpress and utilise HHVM only features, that fork will no longer run on PHP. Future developments and plugins will then be tied to a specific fork causing fragmentation and/or duplication of effort and lots of backporting.

    • ChrisChristoff

      There have been and always will be many forks of WordPress. There are forks of WordPress, that for example, remove backwards compatible PHP code, so that WordPress only runs on faster PHP 5.5 code, therefore tying the fork to newer versions. While these forks could lead to fragmentation, like it did with Drupal 8, WordPress’s community is intensely loyal to the core. I think HHVM’s impact will have broader implications, particularly for places like the Drupal community.

      • http://r.je Tom Butler

        My worry isn’t about wordpress or other individual projects, it’s about the bigger picture and portability as a whole within the PHP community. The more versions of the language there are with different featuresets, the more difficult it is for anyone to release code. Either they have to limit their userbase by targeting a specific implementation or increase their development and testing time ensuring it works on different PHP implementations. With PHP versions it’s less of an issue because there are only 2-3 versions to worry about at any given time. 99.9% of code is forwards compatible and the PHP developers philosophy has always been against changing things in a way that will potentially break existing code. The same is not true of other implementations and HHVM language features will probably never be supported in PHP so any developer who develops HHVM code is severley limiting the portability and userbase of that code.

        What will be worse is if HHVM gets significant market share and becomes popular. We’ll then have two competing languages and a mess where useful projects will only run on one or the other… then we’ll get people duplicating effort by porting projects between HHVM and PHP (And any other implementation that gets widespread use).

        All in all, this fragmentation is bad for the community as a whole. Instead, the HHVM developers should be working to get useful features built into the official PHP release.

  • Grant Wesley Parks

    It’s all unnecessary. What needs improvement is programming skill. Done right, PHP doesn’t need any of this crap. Layer upon layer to do what could be done natively by someone with the proper skills. Lower complexity; stop trying to be Java (since Java is ridiculous).

  • amazzy

    The PHP team has done a great job with what resources they have- they’re practical and suspicious of new bloat which is how software should be developed. Gung-ho kids who throw in every little feature are why you get things like Rails which has a dying user base but was “the way of the future” kind of like a bad 80s sci-fi movie (think captain EO), or things like Gnome 3 which shouldn’t take much explaining. We don’t need this hip skinny jean junk created by people who don’t actually make any real world applications, or are even old enough to have a job yet… Everyone complains about PHP but for some reason they still use it. Get back to designing your web applications, stop complaining, and if you have a real issue submit a patch!