HHVM JIT: A profile-guided, region-based compiler for PHP and Hack | Hacker News Reader

HHVM JIT: A profile-guided, region-based compiler for PHP and Hack

blog.acolyer.org

38 pointsmatt_d15 comments

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.

It has to be php 7. In lots of comparisons, php 7 was performing close to or better than hhvm. And that was before the performance improvement of 7.1 and 7.2

> 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.

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 - The version reflects what you might see in early 2013. It should be dockerized and easy to play with if anyone is interested.

> the previous PHP -> C compiler

I think the transpiler version targeted C++?

Yep, you're totally right. I misspoke.

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.

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?

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

Why not link directly to the FB Research page?

https://research.fb.com/publications/hhvm-jit-a-profile-guid...

Or the paper itself?

https://research.fb.com/wp-content/uploads/2018/04/hhvm-jit-...

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.

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

Thanks for the link to the paper!

The first line of the article is a link to the paper.

And because the link was posted here there's no reason for me to look at the blog post.

Reply on news.ycombinator.com