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 – Facebok’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.

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.

  • gafitescudaniel

    @Bruno at the moment can you have have Phalcon install on HHVM ? I think you can not due to the extension limitation.

  • Kevin

    I prefer the php (6) syntax to be similar to zephirs(that’s a cool syntax that they have, the code looks better)

  • dlsniper

    Or simply everyone will move to other languages like golang for example ;)

    • http://jaf.ar.com/ Jafar

      Im using golang :)

  • http://jaf.ar.com/ Jafar

    I wanna see wordpress on HHVM

  • WooDzu

    Your “dream” of php6 falls somewhat inbetween mine ;) I also like the idea of Zephir replacing php syntax but the top one is to get rid of procedural programming and named functions

  • jymboche

    I spent last weekend benchmarking some existing sites I built against Yii + Zend 5.5 opcache, HHVM 2.4, and phalconphp + opcache. Honestly, Yii + zend 5.5 opcache seemed to perform on equal footing with Yii run through HHVM. And I think because overall the complexity and memory requirements of my sites were nowhere near what facebook deals with. (And my sites never will I’m sure)

    Phalconphp + opcache on the other hand was nearly twice as fast. Plus I can still use all the standard extensions. Phalconphp is young and difficult to find support for (either in docs or forums), but will grow. Using Zephir was a genius move for 2.0 as it lets less hard-core php devs engage in development. Hopefully that will increase adoption. (I enjoyed your last few articles btw!)

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

      Thank you! And thanks for the feedback, very valuable! You think you could benchmark the app objectively and write about it? I’d be happy if we could publish the result. Did you bomb it with Apache benchmark or some other tool?

      • jymboche

        Yeah I’ll try to setup a good objective test soon. I actually didn’t use apache bench. My desktop is OSX 10.9 and I had trouble with apache bench so I used a tool called siege. The server was a small virtual machine on a local box with centos 6.4 and nginx.

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

          VMs + Siege = perfect, let me know when you have something on bruno.skvorc@sitepoint.com!

        • gggeek

          you can take a look at a tool called ezab (written in php) if ab proper does not work for you

  • Larry Garfield

    Python3 Hell… You mean like PHP 5.0, which no one used until 5.2 and the GoPHP5 project? :-)