
LLVM Code Generation in HHVM - bado
http://hhvm.com/blog/10205/llvm-code-generation-in-hhvm
======
chrisseaton
It's great to see a blog post that basically presents a negative result - LLVM
hasn't sped up peak performance and has slowed warmup. Often people will try
something and if it doesn't work well will never write it up so you'll never
hear about it.

~~~
illumen
Indeed. Hearing about how things didn't work out is highly instructional too.

In the past LLVM has been almost completely unusable for dynamic languages.
Not it seems there are dynamic two implementations using it (at least
JavaScriptCore). So this is a pretty good result.

The other good result is that it shows with LLVM other architectures were
supported than x86.

I know at least pypy and unladen swallow have tried to use it in the past (5+
years ago) with no success.

~~~
chrisseaton
Rubinius is also trying LLVM with very limited success. It's really clear you
need an entire IR and optimisation pipeline before you emit LLVM if you are
implementing a dynamic language. Then you're only using LLVM for instruction
selection, scheduling and emitting so it doesn't seem as helpful anymore. Is
there any project trying to provide the IR and pipeline before LLVM which
could work across languages?

------
csours
HHVM, if you were ignorant like me:

HHVM (aka the HipHop Virtual Machine) is an open-source virtual machine
designed for executing programs written in Hack and PHP. HHVM uses a just-in-
time compilation approach to achieve superior performance while maintaining
the flexibility that PHP developers are accustomed to. To date, HHVM (and its
predecessor HPHPc before it) has realized over a 9x increase in web request
throughput and over a 5x reduction in memory consumption for Facebook compared
with the PHP 5.2 engine + APC.

~~~
mappu
More context: PHP 5.2 is an old and slow baseline - improvements of roughly
the same magnitude have happened with PHP.net's PHP over the same time frame.

~~~
kibwen
This is true and the results are commendable, though honestly I believe that
the only reason that Zend upped their game was because competition from
Facebook's efforts lit a fire under their ass.

------
whitenoice
Nice writeup, can anyone explain why fb continues to use php over other
statically types languages? I understand they have a huge code base with php,
but with so many awesome engineers at work is it not possible to migrate
slowly? Or is it because they are really productive with php?

~~~
jwatzman
FB engineer here. We did migrate slowly, to Hack
[http://hacklang.org/](http://hacklang.org/). It's a typed dialect of PHP,
notably with full backwards compatibility, so we didn't have to rewrite all of
our code as we converted over and added types. I haven't looked at the stats
in a while, but last I checked, well over 99% of our files were marked as
having some type information, and a very significant proportion of that was
becoming _fully_ statically typed. Basically all new code since the end of
2013 has been mostly, if not completely, statically typed.

I'm actually giving a talk at OOPSLA this week about how we went about
actually doing the conversion (everything from how we approached designing the
system to how we convinced engineers to use it), if you or anyone reading this
happenes to be going. [http://2015.splashcon.org/event/splash2015-splash-i-
josh-wat...](http://2015.splashcon.org/event/splash2015-splash-i-josh-watzman-
talk) I think it will also be recorded.

------
kibwen
Neat writeup, and very interesting that they haven't found it to be enough of
a performance win to turn it on in production yet.

I was actually most interested to hear about HHIR and their general compiler
pipeline. I'm reminded of Rust's recent initiative to rearchitect the compiler
with a Rust-specific IR of its own (MIR). Here's an overview of how the
compiler devs expect rustc to operate once this work is complete:
[https://github.com/rust-
lang/rfcs/pull/1211#issuecomment-128...](https://github.com/rust-
lang/rfcs/pull/1211#issuecomment-128031104) and here's a comment expanding on
this overview: [https://github.com/rust-
lang/rfcs/pull/1211#issuecomment-130...](https://github.com/rust-
lang/rfcs/pull/1211#issuecomment-130116684)

~~~
jwatzman
> I was actually most interested to hear about HHIR and their general compiler
> pipeline.

You might also be interested in this post, which goes into some more detail
about HHBC and HHIR, and gives some examples of what it looked like about a
year ago (which hasn't changed to terribly much):
[http://hhvm.com/blog/6323/the-journey-of-a-thousand-
bytecode...](http://hhvm.com/blog/6323/the-journey-of-a-thousand-bytecodes)

------
aorth
Bravo to them for publishing negative results. Bias towards only publishing
positive results is a problem in academia. At the institute where I work
scientists are often reminded that "No results are also results!"

