PHP 8: The JIT
Heads up! I've done some benchmarks on the JIT in real-life web applications. Be sure to check them out.
Dmitry Stogov recently opened an RFC to add a JIT compiler to PHP. So, what is that about? Does "JIT" mean "instantly better PHP", or is this a more nuanced topic? Today we'll briefly look at what the "JIT" actually does, and more importantly: the difficulties and opportunities it brings to the PHP world.
# What is JIT?
"JIT" stands for "just in time". You probably know that PHP is an interpreted language: it's not compiled like a C, Java or Rust program. Instead it is translated to machine code — stuff the CPU understands — at runtime.
"JIT" is a technique that will compile parts of the code at runtime, so that the compiled version can be used instead.
Think of it like a "cached version" of the interpreted code, generated at runtime.
How does that work, you ask?
There's a so called "monitor" that will look at the code as it's running. When this monitor detects parts of your code that are re-executed, it will mark those parts as "warm" or "hot", depending on the frequency. These hot parts can be compiled as optimised machine code, and used on the fly instead of the real code.
You can imagine there's a lot more complexity to this topic. If you want to know a little more, you can check out Mozilla's crash course in JIT compilers. For the purpose of this blog post, it's enough to understand that a JIT compiler may improve the performance of your program significantly, but it's a difficult thing to get right.
Zeev, one of the PHP core developers, showed a demo with fractal generation a while back:
Fancy, right? Hold on though…
# It's not all fun and games
Let's address the elephpant in the room: PHP is seldom used to generate fractal animations.
Knowing that the JIT compiler tries to identify hot parts of your code, you can guess why it has such an impact on the fractal example: there's a lot of the same calculations happening over and over again. However, since PHP is most often used in a web context, we should also measure the JIT's impact there.
It turns out that, unfortunately, there's a lot less hot code while handling a web request. This doesn't mean the JIT couldn't improve web performance at all, but we also won't see similar improvements like with the fractal example.
Is this a reason to ditch the JIT? Definitely not! There are good arguments to add it, even though it might not have the performance impact we'd hope for.
- It opens the door for PHP to be used as a very performant language outside of the web.
- The JIT can be improved upon over time, as well could our code.
These are valid arguments in favour of the JIT. Unfortunately though, there are also more arguments against it.
# A complexity to maintain
Because the JIT generates machine code, you can imagine it's complex material for a "higher level programmer" to understand.
For example: having machine code as output, it will be harder to debug possible bugs in PHP's JIT compiler. Luckily there are tools to help debugging. But still, it is machine code. Say there is a bug in the JIT compiler, you need a developer who knows how to fix it. Dmitry is the one who did most of the coding up until now, and remember that PHP core development is done on a voluntary basis.
With just a few people being able to maintain such a code base today, the question whether the JIT compiler can be maintained properly seems justified. Of course people can learn how the compiler works. But it is complex material nevertheless. The pull request right now counts around 50k lines of added code. And mind you: this is not your average client-web-application-codebase. This is almost-as-close-as-you-can-get-to-the-CPU-programming.
Again this should not be a reason to ditch the JIT, but the cost of maintenance should be carefully considered. In first place by the ones who have to maintain the code; but also by the userland community, who should also be aware that some bugfixes or version updates might take longer than what we're used to right now.
Cross platform?
As of newer versions of the JIT, it now also works Windows and Mac! A big step forward, and definitely worth mentioning.
# So why would you want it?
If right now you're thinking that the JIT offers little short-term benefits for your web applications, you might be right. It's difficult to tell what impact it will have on production applications, before actually using it.
The JIT RFC proposed to enable it in PHP 8, but also to add an experimental version in PHP 7.4. Unfortunately the RFC has passed for PHP 8, but not for 7.4. This means we'll have to wait until PHP 8 before being able to try it out on real projects. You can of course compile PHP 8 from source, if you already want to take a look.
Even though the JIT might not offer any significant short-term improvements, we should remember that it will open a lot of possibilities for PHP to grow, both as a web language and a more generally purposed language. So the question that needs answering: is this possibly bright future worth the investment today?
What do you, the userland programmer think? Let's discuss it on Hacker News. If you want to personally reach out, you can find me on Twitter or via e-mail!
