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