Facebook Decides Against Rolling Their LLVM Back-End For HHVM Into Production
We've known about HHVM developers working on LLVM support for their PHP/Hack interpreter, but now the Facebook developers have shared they've decided against rolling out their new LLVM support into production.
Posted to the HHVM blog yesterday was about LLVM code generation in HHVM. Long story short, they added the steps to lower from their VASM IR (a lower-level IR than HHIR and in their conventional implementation just one step away from x86-64 machine code) to LLVM IR, then using LLVM to generate the final x86 machine code for this JIT compiler with the dynamically-typed PHP/Hack.
While they got this LLVM implementation working, they didn't find the LLVM performance to be dramatically different in either direction than their own custom implementation. So they concluded, "Making such a large change across the whole web fleet always comes with risk, and without a performance improvement to justify the risk it’s not worth it. We aren’t giving up, though—HHVM is still relatively young compared to other similar JITs, with plenty of room to grow in ways that may benefit the LLVM backend. We only recently implemented support for compiling loops within a single compilation unit, and as our HHIR optimizations become more sophisticated, the code we give to LLVM may start to look more and more like C code, which is what LLVM excels at optimizing. And JavaScriptCore has implemented their own LLVM backend with great results, which is very encouraging for the potential of using LLVM in a mature dynamic language JIT."
Posted to the HHVM blog yesterday was about LLVM code generation in HHVM. Long story short, they added the steps to lower from their VASM IR (a lower-level IR than HHIR and in their conventional implementation just one step away from x86-64 machine code) to LLVM IR, then using LLVM to generate the final x86 machine code for this JIT compiler with the dynamically-typed PHP/Hack.
While they got this LLVM implementation working, they didn't find the LLVM performance to be dramatically different in either direction than their own custom implementation. So they concluded, "Making such a large change across the whole web fleet always comes with risk, and without a performance improvement to justify the risk it’s not worth it. We aren’t giving up, though—HHVM is still relatively young compared to other similar JITs, with plenty of room to grow in ways that may benefit the LLVM backend. We only recently implemented support for compiling loops within a single compilation unit, and as our HHIR optimizations become more sophisticated, the code we give to LLVM may start to look more and more like C code, which is what LLVM excels at optimizing. And JavaScriptCore has implemented their own LLVM backend with great results, which is very encouraging for the potential of using LLVM in a mature dynamic language JIT."
1 Comment