LLVM Code Generation in HHVM

106 points by bado 10 years ago | 16 comments

chrisseaton 10 years ago |

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 10 years ago | |

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 10 years ago | | |

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?

michel-slm 10 years ago | | |

Unladen Swallow was abandoned, but for Python there is now Dropbox's Pyston - https://github.com/dropbox/pyston

csours 10 years ago |

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 10 years ago | |

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 10 years ago | | |

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.

mgkimsal 10 years ago | | |

indeed. for some comparison just betwwen php 5.4, 5.5, 5.6, 7, and HHVM, view some benchmark results in recent PHP talks...

http://talks.php.net/singapore15#/drupalbench

php7 is sometimes faster than hhvm, and sometimes a bit slower, but both are generally faster to much faster than earlier versions.

(and 5.4 was faster than 5.2 which the GP referenced)

whitenoice 10 years ago |

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 10 years ago | |

FB engineer here. We did migrate slowly, to Hack 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... I think it will also be recorded.

TazeTSchnitzel 10 years ago | |

> Nice writeup, can anyone explain why fb continues to use php over other statically types languages?

When you have a large existing codebase in one language, migrating it to a new language means a massive amount of time wasted retraining engineers, rewriting code, etc. You lose a lot of productivity and spend a lot of money for possibly little gain.

croddin 10 years ago | |

Well the made the hack language, which is php with types. I don't know how much they use it, but it seems like that is at least a move in the right direction.

JoeAltmaier 10 years ago | |

It could have something to do with their hiring process being a large machine for producing 'cultural fits' which means, people who think exactly like they already think. They have 3 or 4 layers of interview, followed by candidates attending a bootcamp where they are indoctrinated into the One True Facebook Way.

kibwen 10 years ago |

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... and here's a comment expanding on this overview: https://github.com/rust-lang/rfcs/pull/1211#issuecomment-130...

jwatzman 10 years ago | |

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

aorth 10 years ago |

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!"