HHVM vs Zend Engine in PHP 6

Bruno Skvorc
Bruno Skvorc
Share

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.

Frequently Asked Questions about HHVM and Zend Engine PHP 6

What are the main differences between HHVM and Zend Engine PHP 6?

HHVM (HipHop Virtual Machine) and Zend Engine PHP 6 are both engines that power PHP, but they have some key differences. HHVM, developed by Facebook, uses a just-in-time (JIT) compilation approach to achieve superior performance, while Zend Engine, the default engine for PHP, uses an interpreter. This means that HHVM can often execute PHP code faster than Zend Engine. However, Zend Engine PHP 6 has a wider compatibility with PHP scripts and offers more stability.

How does the performance of HHVM compare to Zend Engine PHP 6?

HHVM generally performs faster than Zend Engine PHP 6 due to its JIT compilation approach. It translates the PHP or Hack code into a high-level bytecode which is then translated into machine code at runtime. This allows for faster execution of scripts. However, the performance can vary depending on the specific use case and the type of code being executed.

Is HHVM compatible with all PHP code?

While HHVM aims to be compatible with the majority of PHP code, there may be some exceptions. HHVM was developed by Facebook with a focus on performance, and as such, it may not support all PHP features, particularly those that are rarely used or not considered best practices. It’s always recommended to thoroughly test your PHP code on HHVM before deploying.

What are the advantages of using Zend Engine PHP 6?

Zend Engine PHP 6 is the engine that powers PHP by default, meaning it has wide compatibility with PHP scripts. It’s also known for its stability and reliability. Additionally, Zend Engine PHP 6 supports numerous extensions and features that may not be supported by HHVM.

Can I switch from Zend Engine to HHVM?

Yes, it’s possible to switch from Zend Engine to HHVM, but it’s important to thoroughly test your PHP code on HHVM before making the switch. While HHVM can offer performance improvements, it may not support all PHP features or extensions that you’re using with Zend Engine.

Is Zend Engine PHP 6 still being developed and maintained?

Yes, Zend Engine is still being actively developed and maintained. It’s the default engine for PHP, and it continues to receive updates and improvements.

What is the future of HHVM?

HHVM continues to be developed and maintained by Facebook. However, as of version 3.30, HHVM no longer aims to support PHP, and instead focuses on Hack, a programming language developed by Facebook that is based on PHP.

What is the JIT compilation in HHVM?

JIT, or Just-In-Time compilation, is a feature of HHVM that allows it to execute PHP code faster. It works by translating the PHP code into a high-level bytecode, which is then translated into machine code at runtime. This allows for faster execution of scripts compared to an interpreter.

What is Hack, and how does it relate to HHVM?

Hack is a programming language developed by Facebook that is based on PHP. It’s designed to be faster and safer than PHP, with added features like static typing. HHVM is the engine that powers Hack, and as of version 3.30, HHVM focuses on supporting Hack rather than PHP.

Can I use PHP extensions with HHVM?

HHVM supports many PHP extensions, but not all. Some extensions may not work with HHVM, particularly those that are not widely used or not considered best practices. It’s recommended to test any extensions thoroughly when switching to HHVM.