31

Can we expect a speed gain by transitioning from PHP to Hack on HHVM?

I'm thinking of the strongly typed parameters / return types, in particular scalars, does that allow HHVM to do a better job at compiling the code to native code, or is the speed gain insignificant as compared to using classic PHP and its mixed types?

BenMorel
  • 30,280
  • 40
  • 163
  • 285
  • 3
    @Mark I could of course do some little benchmarks, but I have no idea whether they would be representative. I'm more interested in the theory behind this, by someone having insights in to how the HHVM JIT compiler works at its core. – BenMorel Sep 29 '14 at 10:38
  • 1
    Well if you're talking about both switching platform, and switching language.... hard to get an honest measurement from one or the other if you're comparing two big changes... you'd almost certainly see a speed change switching from say Apache/mod_php to hhvm/php – Mark Baker Sep 29 '14 at 10:43
  • 1
    The best way to find out if a method is faster is to test the speed of it. Time each occurrence and see which is faster. I do it with almost every idea I want to try. – backend_dev_123 Sep 29 '14 at 10:58
  • 1
    Well what you both say is true, but again, I like not only benchmarks, but also a bit of theory. @Mark, I'm confident the speed gain from mod_php to HHVM is huge. What I'm interested in, is: if I make the switch to HHVM, would speed be a determining factor in the choice between the Hack language and the PHP language? – BenMorel Sep 29 '14 at 11:30
  • 1
    I've given a full answer below that I think addresses both the "in theory what does the speedup look like" and "would speed be a determining factor in the choice between Hack and PHP". But as with any perf question, even given what I say below, the advice to run your own benchmarks for things that are important to you is good advice. – Josh Watzman Sep 29 '14 at 12:42

1 Answers1

77

I answered this on Reddit a few months back. I've copied my answer below, since the state of the world hasn't changed much since then. But keep in mind that HHVM is still evolving, pretty quickly actually, and so this could easily be out of date in a month or two more.

I work on the Hack team at Facebook. The answer to this question is somewhat subtle.

Moving your PHP code from PHP5 to HHVM is likely to result in a significant speedup, as others have said. How significant depends on a ton of factors. If you're already IO bound, you may not see much at all; if you are closer to CPU bound, speedups of up to something like 5x have been reported, though you are likely to get something somewhere inbetween. You should go and try it on your own code, with a real workload -- HHVM has a bunch of factors, notably a larger startup time, that make it not do so well on microbenchmarks, but on real workloads it should outperform PHP5. For maximum benefit, refactoring your code to get things out of toplevel and into functions/classes will help a ton (we can't JIT code at toplevel), as will setting up repo authoritative mode.

But that's just plain PHP on HHVM, not Hack on HHVM. What speedup do you get from then converting your code to Hack? It depends on how you do the conversion, but the answer is, at least right now, "not very much". If you just go stick <?hh at the top of every file, instead of <?php, and fix any incompatibilities that come up when you run the typechecker, then your code will very likely perform the same as before. Hack and PHP code have the same runtime representation, so you haven't really changed much.

If you do that, though, then you aren't taking full advantage of Hack! If you go in and start adding type annotations, you can build up more and more information for HHVM to use at runtime. This process is what can speed up your code -- HHVM can generate type-specialized (i.e., faster) code in a lot of circumstances where before it might have not been able to infer the type. Don't expect a huge speedup here either -- this is largely theoretical right now, and there are lots of places we can be taking better advantage of the type information to generate faster code. (We don't do much with return types at runtime right now, for example.) But this is the part that might help, and might help more as HHVM gets smarter.

But of course, keep in mind that execution speed wasn't the point of Hack -- it was about developer efficiency. Any performance gain is probably not going to be worth the effort going from PHP on HHVM to Hack on HHVM. The gain in developer productivity, though, probably is.

So does moving from PHP5 to HHVM speed up your code? Very likely. Does doing a quick conversion to Hack speed it up? No. Does adding more type annotations speed it up? Maybe a little, maybe more in the future, but that's not really the point.

Josh Watzman
  • 6,460
  • 1
  • 16
  • 26
  • 1
    Excellent summation from an insider, so certainly good insight and advice into the benefits – Mark Baker Sep 29 '14 at 14:42
  • 4
    Update Feb 2015: the above answer is still mostly true. The only change of note is that we've started taking better advantage of return types for performance optimizations, as of HHVM 3.5 or so. – Josh Watzman Feb 22 '15 at 23:09
  • Now that PHP 7 has scalar type hints and return types, I guess that HHVM can perform similar optimizations when running PHP code? – BenMorel May 03 '16 at 08:20
  • 1
    I'm not sure how much HHVM optimises PHP7 types -- they are trickier since they can coerce instead of error, based on configuration of the *caller*. That's somewhat more complicated checking than in Hack. – Josh Watzman May 07 '16 at 13:49
  • PHP 7 is much faster than PHP 5, almost as fast as HHVM. And it supports scalar type hints so no need to use Hack. – Vahid Amiri Mar 27 '17 at 13:45
  • PHP 7 is lacking a static analysis tool like `hh_client` to find your type errors before runtime, which is one of the key facets of Hack. Purely performance-wise, it also lacks a JIT to take greatest advantage of type specialisation -- though whether your code actually runs faster on HHVM due to this (and many other factors) is extremely complicated and something you should determine via profiling. – Josh Watzman Apr 14 '17 at 18:34