
HHVM JIT: A profile-guided, region-based compiler for PHP and Hack - matt_d
https://blog.acolyer.org/2018/08/08/hhvm-jit-a-profile-guided-region-based-compiler-for-php-and-hack/
======
gravypod
I've been looking at ways I could squeeze more performance out of my long
running PHP jobs (wasn't my decision to write it in PHP) at work and HHVM was
very attractive due to the extreme focus on JIT optimizations. Unfortunately
it doesn't seem like any major framework still supports HHVM officially. Even
artisan dies when I try to run it unfortunately. At one point I remember
everyone pushing to support HHVM, that effort seems to have stopped. Does
anyone know why this happened? Was this just performance improvements of PHP
7? JIT optimizations like this would really shine in longer-running use cases.

~~~
bastawhiz
> Does anyone know why this happened?

I was at Box at the "peak" of the HHVM hype. Honestly, the biggest thing that
doomed HHVM in my eyes was lack of macOS support. You simply couldn't run it
on your MacBook. Invariably, that meant you had to have a VM somewhere running
it, and that made debugging compatibility issues really difficult. Finding and
reporting issues was a grueling process and made it almost impossible for most
folks to offer meaningful contributions.

When PHP 7 was announced, all the attention that was on HHVM was split between
HHVM and the official Zend solution. Folks didn't want to take up HHVM support
if PHP 7 turned out to be amazing. IIRC, Etsy–who employ(s|ed) Rasmus
Lerdorf–was a major holdout and drove a lot of mindshare away from HHVM. By
the time HHVM got to a point where it was "reasonably good" to work on, PHP 7
was out. And the performance was pretty much comparable for most workloads.

Nobody really ever cared about Hack. Nice things like compiling your PHP code
into a sqlite database (I forget what they called it) was really hard to do
for a codebase that didn't start on HHVM or used many dependencies. I remember
bumping into some unfortunate performance issues around regular expressions
and spooky Unicode support bugs. The benefits weren't really compelling and
the drawbacks were hard to overcome.

At the end of the day, it was just bad timing (or, you could argue "too little
too late") and being developer-unfriendly. Getting your Drupal site moved to
PHP 7 was an infinitely simpler choice than getting it running on HHVM, even
if HHVM had a 20% perf advantage.

------
awirth
The development of HHVM is really interesting. I spent some time a while ago
dockerizing an old version of HPHPc (the previous PHP -> C compiler which HHVM
grew out of) and put it up at [https://github.com/allanlw/hphpc-
docker](https://github.com/allanlw/hphpc-docker) \- The version reflects what
you might see in early 2013. It should be dockerized and easy to play with if
anyone is interested.

~~~
chrisseaton
> the previous PHP -> C compiler

I think the transpiler version targeted C++?

~~~
awirth
Yep, you're totally right. I misspoke.

------
obl
Half a gig of machine code...

In the paper they mention trying to limit the code size to 10% of that and
getting ~60% of the baseline perf.

However, they got this number by simply dropping to the interpreter for the
rest of the code. I'm curious what kind of figures they'd get if they got to
this 10% goal by being more aggressive in the type guard widening pass.

------
hajile
PHP 7 is very close to HHVM in performance (and often faster) when looking at
common frameworks. Does this situation change significantly when you use hack
for static types?

~~~
sanxiyn
No. Hack's type system is unsound and HHVM discards all type information from
Hack.

------
debacle
Why not link directly to the FB Research page?

[https://research.fb.com/publications/hhvm-jit-a-profile-
guid...](https://research.fb.com/publications/hhvm-jit-a-profile-guided-
region-based-compiler-for-php-and-hack/)

Or the paper itself?

[https://research.fb.com/wp-content/uploads/2018/04/hhvm-
jit-...](https://research.fb.com/wp-content/uploads/2018/04/hhvm-jit-a-
profile-guided-region-based-compiler-for-php-and-hack.pdf)

~~~
chrisseaton
Because those are technical literature that aren't easy for most people to
understand.

The linked page gives a layman's explanation of the research, which is going
to be accessible for the general HN audience.

Why not just link to the source code directly if you're that hardcore and
don't care about any higher level description? Or how about a hexdump of the
binary?

Commentary is useful.

~~~
debacle
There's no real commentary in the original post. It's a relatively liberal
copy/paste summarization of the research paper.

