We do a lot of PHP work here at Press Up. Not only do we do WordPress, but we use the language on its own for many small projects, and we’ve run more than a few projects built atop of other PHP packages, libraries, and frameworks. PHP is the ugly step-child that every programmer loves to hate, but we rely on it a lot (for reasons expanded on in “Why PHP?“).

Lately if you’re vaguely aware of PHP you’ve probably more than once come across the term HHVM. Maybe it’s that a framework you’re using or thinking about has announced it runs on the HHVM. Maybe it’s that you’ve heard someone gloating about how they made their site faster with the HHVM. Or maybe you’ve just seen it floating in the ether. If any of those are the case for you — or you’re just idly curious and don’t feel like you really “get” HHVM — this is the post for you.

The Origins of HipHop at Facebook

The HHVM actually has a pretty long history. Facebook — the world’s largest social network — is largely a PHP-based server-side stack. As such, they’ve spent a large part of the last 10 years working on the performance of PHP and the code they’ve written on top of it. They first used the term, HPHP, or HipHop — which is a popular style of music with the “youths” and also conveniently has the letters “P-H-P” in it in the correct order — in relation to a technology that “transpiled” PHP into C++ code.

“Transpilation” is a interesting and kind of esoteric idea, but in it you’re trying to get certain compatibility (or in this case, performance) by “switching” languages before you run. PHP isn’t all that performant a language when you compare to something that’s “closer to the metal” — creating clean instructions that a processor can run without any thought or esoterica. Without getting too exact, CPUs run a very small set of logic operations at extreme speed, and “higher-level” languages rely on more layers of abstraction and simplification to make programming easier for humans. These layers of abstraction make languages like PHP, Javascript, Python, or Ruby generally less performant than languages like Assembly, C, or C++.

These layers of abstraction make languages like PHP, Javascript, Python, or Ruby generally less performant than languages like Assembly, C, or C++.

So the purpose of “transpiling PHP” was to make the execution more performant than it otherwise would be, and HPHPc was doing that for Facebook. Their PHP would become C++ code, which could then be compiled into instructions that ran much faster than PHP. To keep this piece a manageable length, we won’t get into how exactly this situation was a bit of headache for actual engineers in the day-to-day working on Facebook, but let’s just know that while HPHPc (and HPHPi) worked for some of Facebook’s goals, they weren’t fully satisfied.

HipHop Virtual Machine: What’s in a Name?

To solve the problems of HPHPc, Facebook decided to change tack and create a “PHP virtual machine” — the HipHop Virtual Machine, HHVM — which doesn’t take the intermediate step of making C++ from PHP, and simplifies the way PHP runs itself on the CPU.

Again, we’ll try to make this as simple as possible: a “virtual machine” is a concept by which a language’s code is translated into something that a CPU can’t itself run, but which is closer to what a CPU runs than the language the programmer is using. The purpose of a “virtual machine” is that it allows for two great things: active, or “just in time” (which is often abbreviated as JIT) optimization of the code while it is running, and for the same code to work on CPUs which have different types of low-level instructions. (If you’ve ever heard the terms “x86” or “x64“, those are the kind of low-level instructions that most Intel processors use and understand. But your smart phone probably uses the “ARM instruction set“, which is not directly compatible with x86.) By having the “virtual machine” layer between the programmer and the CPU, both high performance and wide compatibility are possible.

So the HHVM is a essentially that — a “virtual machine” that allows for PHP to run more efficiently than it does in the default implementation, and allows for lots of optimizations for certain code because it can optimize performance as it watches the code run. This ability to optimize “just in time” is especially powerful when you’ve got tight small simple loops in a program, and you can make the instructions to the CPU super efficient as you watch that loop get used a lot. (The multiple-processor-architecture facet of the virtual machine concept is not currently used in the HHVM, which only compiles to x64 — which is what’s used on most servers in the world — instructions.)

Let’s Talk about Compatibility

An obvious question you might be wondering is: if the HHVM is faster, why doesn’t everyone use it? Well, there are a few different reasons that you might not.

The first is that because it’s only being written by Facebook — where as the “default” or “Zend Engine” version of PHP is and always has been open source and built by the community. So, you might not want to switch for purely strategic or political reasons. Facebook has been rather open about HHVM, their goals, and their direction, but it is being made by Facebook, and they clearly drive its future.

More practically, HHVM isn’t completely and exactly the same as “default” PHP. For differing reasons — some performance based, and some preference based — there are subtle difference between how PHP code behaves in a few situations on the two different “engines”. Additionally, PHP code often relies on “PECL extensions“, which aren’t yet all compatible with HHVM PHP. The details of what these extensions are are a bit beyond the scope I want to tackle here, but essentially they’re the way a lot of the more interesting and complicated things in PHP are built, and relied on by a non-zero amount of executing and valuable PHP. Facebook is actively working to get these all working with the HHVM, but they’ve not got a massive team doing it, and so they still aren’t all ready to go.

Another concern, which diminishes with time, is that you just prefer stability to speed. While HHVM is clearly used in production at Facebook, and slowly being used elsewhere in the development community, the possibility that you’re going to be the first one to discover some problematic behavior in the application you’re depending on constantly being stable and available is a lot higher in a less-used technology like HHVM than it is on something as widely-used as PHP. (This is a general principle, not a specific opinion of PHP and the HHVM.)

So In Short…

The shortest possible summary of what the HHVM is this: “a way to run PHP faster.”

The shortest possible summary of what the HHVM is this: “a way to run PHP faster.” But as I hope you understand from reading this explanation, that doesn’t really scratch the surface of what’s going on. Because of the type of activity and technology it’s using, the way the language is subtly different, and the way it’s controlled, you’re making distinct tradeoffs in the swap. Whether it’s valuable to you, and if it’ll work perfectly for your application are still things that require a detailed understanding of your specific situation to answer.

I think so far HHVM has introduced an awesome disruptive force in the PHP community, and it has been and will be really exciting to see where it goes. The HHVM team are going to great lengths to make sure that the most popular PHP web applications and frameworks — everything from WordPress to Doctrine and Laravel — work with it. And we’ve not even touched the “PHP-like” language Facebook has created called “Hack”) which also runs on the HHVM. It’s all quite cool, and the barriers to it being ready for prime-time are dropping quickly. Watch out for the HHVM!