HHVM vs Zend Engine in PHP 6

The fabled PHP 6 is long overdue. This unicorn of the web dev world has been “coming” for decades now, and it’s still not clear whether or not it’s actually something that’s going to happen in this decade, or just an idea, a fantasy of the PHP userbase. Minor versions like 5.4 > 5.5 and 5.5 > 5.6 bring so many new features these days anyway, we often see them as major versions.

My own personal fantasy for v6 is function naming consistency, a total break of backwards compatibility with PHP <6 in terms of global namespace pollution, and a full rewrite of all data types to classes much like in Scala or Dart, but hey, we all have our wild dreams.

For a great article on the unfortunate fate of PHP 6, please see here – and make sure you don’t skip the comments. There are some valuable lessons about the attitudes of core PHP devs to be learned there.

The premise

Not many people know this, but http://www.phpclasses.org has some interesting, if very awkward podcasts rather often. It’s sometimes difficult to weed out the useful information from these talks, but Manuel’s contents list usually helps. If you’re curious about changes in PHP and keeping up with the latest news, why not fire it up while exercising, coding, cooking or whatever else? In the latest edition between Manuel Lemos and César Rodas, an interesting topic arose among others – Facebook’s HHVM replacing Zend Engine in PHP 6.

While this was purely speculation on the part of the participants, and whether or not you believe in PHP 6, you have to admit it’s an interesting notion. As we’ve seen in the HHVM article, and on the HHVM blog, HHVM has been making strides in becoming compatible with most of the popular libraries, CMS, and frameworks out there. The team is doing what it can to improve performance as much as possible while keeping it compatible with existing codebases for various products. Let’s entertain the possibility of HHVM replacing ZE in PHP 6 and look at the pros and cons.

The pros

Obviously, performance. HHVM is leaps and bounds faster than vanilla PHP, even with the default built in OpCache in 5.5. It uses fewer resources to do things faster. One can’t not see the advantages of this – consider, if you will, just the savings on cloud deployment bills. Fewer CPU and RAM usage means fewer instance hours.

The next advantage is HHVM being backed by Facebook. Facebook uses HHVM to deploy their own PHP code, so they need to make sure it’s as efficient as possible. A 1% CPU spike means tens of thousands of dollars in expenses for them, so it’s only natural they’d rather throw that money at the HHVM team to make sure it never happens. As a result, HHVM is being developed by people far more experienced and focused – especially in today’s high-concurrency high-traffic world – than the actual core developers of Zend Engine and PHP. As an example, consider the fact that Facebook had generators in PHP three years before they made it into the mainstream PHP release.

A further advantage is the ability to statically type in the most recent version of HHVM, via their internally developed Hack “language”. Hack is a derivate of PHP, but supports static typing. You start files you want to type check before compilation with <?hh instead of <?php, and the compiler does the rest. A more detailed article on Hack is in the works and will be published soon. This approach further increases the quality of compilation, making native code that much more efficient, and HHVM’s PHP that much faster.

Is it really all about speed, though?

The cons

One of the main cons of HHVM at this moment is the inability to install custom extensions that depend on Zend Engine. As Cesar puts it – HHVM and ZE are like two cars that look alike, but their internals are completely different.

I would expand on the metaphor by saying the two cars have different engines, or different gear shifting systems. Trying to install Nitrous Oxide into an electric car simply won’t work, no matter how hard you try, because NOS depends on the combustion process which is absent in electric vehicles.

This, unfortunately, means most of today’s extensions won’t be installable on HHVM unless converted, and since most extensions are open source projects that don’t get their developers paid, the situation reeks of a possible Python3-hell*.

Another disadvantage is also the same one we listed under pros – it’s developed by Facebook. While Facebook is still healthy these days, Cesar and Manuel speculate that it might suffer a decline in the coming years, and I tend to agree. Moreover, there is the possibility of Facebook making the daring attempt to move away from PHP altogether to something even faster and more structured like Dart – what happens if either of these scenarios occur? HHVM is open source, yes, but without Facebook’s bank and experienced hands behind it, and without a multi-billion userbase to regularly test and benchmark against, the development of HHVM will slow down drastically. The open source community simply lacks the expertise, resources and dedication to take over properly.

Last but not least, there are already efforts to drastically improve PHP’s speed via other means. The Phalcon framework, which we’ve covered extensively, is already written in C and blazingly fast, and with their Zephir language, users can easily write actual PHP extensions for the Zend Engine version of PHP. This means closed source and/or compiled PHP applications that already work at near native speeds, almost rivaling HHVM.

Conclusion

There is no clear winning scenario here. If HHVM replaces ZE, the PHP community will benefit, though the new version might suffer in userbase size until HHVM can support common extensions, or until extensions are rewritten for it. If it remains as a separate project, we have two schools of thought – relying on vanilla HHVM and Hack to compile our frameworks and classes to the best possible native code, or relying on good old ZE PHP, our old extensions, and making do with cutting edge languages and frameworks like Phalcon and Zephir.

How ever you look at it, it’s clear PHP is ready for a new dawn. The advent of variadic function support and argument unpacking similar to that in other mainstream languages proves its readiness to mature, and excellent efforts by high quality low level developers drive the language and its runtime forward like never before. For us, the PHP users, the only way to lose this game is by not playing it at all.

Let’s not leave anyone behind. Got HHVM/Hack and/or Phalcon/Zephir tutorials? Throw them our way.

*Python3-hell refers to the fact that Python3 has been out for over 3 years now, is an improvement over Python2, and still has little adoption when compared to Python2.