Some comments from the maintainer of parrot, p2 and perl B::CC which do similar things:<p>tracelets instead of basic blocks analysis sounds interesting, but php is still doomed by not allowing optional types. In-house code can easily be optimized by explicit types. The AUTOLOAD problem is a big one, and I am just planning to tackle it, but came to the same design decisions mostly. We are compiling modules, files as this is easiest to handle. My p2 jit has no type guards and seperate specialized methods yet, I rather support optional early binding, a jitted method cache and small tagged data, which doesn't fill up the cache that much. It outperforms java and clr by far, just luajit is ahead.<p>With the static B::CC, type inference has the same problem as php, but has the same performance advantages as hhpc, but I added special syntax for typed and sized arrays, and to disallow too much runtime magic. The current production compiler at Cpanel only uses better data layout to get its performance boost at startup and overall memory usage. Readonly strings and hash keys mostly. Perfect hashes not yet.
IMHO most important is smaller data and ops overhead, not the optimizer.
I'm migrating to HHVM across my whole stack. Massive performance gains, only issues have been with some plugins that I was able to pretty easily work around.<p>Good stuff! Uncached, HHVM outperforms my cached php-fpm sites.
Question to the authors: Any reason why hippyvm is not included for comparison in the paper? It does usually outperform hhvm on those benchmarks (but not on real world use cases which is maybe a good reason to include real world use cases more into such papers).
This is awesome! I am not familiar with how compilers/VMs are generally implemented, but the tracelets and guards idea strikes me as very general - in particular, it looks like this approach could be applied to provide type inference to any dynamically typed language. Has this kind of thing been tried before?<p>In terms of optimization, is it possible to create tracelets that are not continuous regions in code? Roughly, if you identify two non contiguous tracelets, having the same inputs, and can guarantee the inputs havent changed in between, then you could merge them together. Because bigger tracelets would mean less guards and better performance.
I assume latent type means simply the implicit typing. i.e. you declare a variable with the value, and the type is inferred through the value of the variable rather than the explicit type declared.
So, a couple of questions:<p>a. Does the HHVM JIT do anything that LuaJIT doesn't? I assume you are familiar with LuaJIT, as it is mentioned in the paper - and from a quick scan, the only two things I didn't recognize from LuaJIT were the refcount optimizations (not required by Lua GC) and guard relaxation.<p>b. Is HHIR tied to Php, or is it usable as a general purpose JIT backend? LuaJIT's IR is, (unfortunately for other languages) tied very strongly to Lua semantics.<p>Thanks for an interesting read!
I'm using HHVM in production for a few weeks now and all I can say is I'm very happy with the results.
It's running stable (compiled under CentOS7) and I was able to cut the response times in half (~145ms with php-fpm, ~70ms HHVM).