Hacker News Reader

Comment by jrockway | Hacker News Reader

PHP doesn’t really need a JIT. Server side programs in PHP don’t do a great deal of dynamic stuff, and it would be incredibly rare to load some random code at run-time, so a JIT wouldn’t be all that useful.

Uh, what? JIT compilers even improve the performance of C. Loading code at runtime and having a JIT are totally orthogonal.

If you're a language like PHP where you can't guess if a value is going to be a hash or the number 42 until runtime, JIT techniques are essential to get any reasonable performance. (Ah, here comes the argument, "PHP apps are never CPU-bound.")

It is odd that the article claims that JITs for dynamic languages are never successful; there is V8 and TraceMonkey, and Parrot optimizes Perl 6 pretty well. Java is fast because of its JIT. The author claims that LLVM's JIT compilation doesn't work, but that's untrue; LLVM's JIT works just fine for C. LLVM's C runs faster than GCC's statically-compiled C, anyway.

View on HN

I'm making the point that you don't need a JIT to get good performance out of compiled PHP. A JIT would be useful, but not required.

> If you're a language like PHP where you can't guess if a value is going to be a hash or the number 42 until runtime, JIT techniques are essential to get any reasonable performance.

Not true, according to my research. You can pretty much tell the type of a value at analysis-time in PHP. Its expensive analysis though.

It would be useful to be able to make some assumptions and back them out at run-time though, like assuming that the sum of two integers is an integer.

> It is odd that the article claims that JITs for dynamic languages are never successful; there is V8 and TraceMonkey, and Parrot optimizes Perl 6 pretty well. Java is fast because of its JIT. The author claims that LLVM's JIT compilation doesn't work, but that's untrue;

I'm not sure where any of this is coming from. I never claimed these things.

I've never seen performance statistics for the LLVM JIT. Link? I've also never seen stats where LLVM beats GCC in execution time of compiled code.

"I've also never seen stats where LLVM beats GCC in execution time of compiled code."

http://leonardo-m.livejournal.com/73732.html

http://www.phoronix.com/scan.php?page=article&item=apple...

Results are mixed, with llvm-gcc generally being slightly slower. There are some benchmarks where it's much slower, and also a few where it's actually faster than GCC. So yeah, there are tasks where LLVM beats GCC in execution time of compiled code.

Rumor has it that parts of Snow Leopard are built with llvm-gcc. Presumably Apple would benchmark both alternatives and only build the parts that are actually faster with LLVM.

LLVM isn't used as a JIT for C in any existing compilers (clang, llvm-gcc, etc) as far as I know; It's used to emit static object code. (If I'm wrong, of course, I'd appreciate a pointer to the projects)

clang and llvm-gcc are two front-ends which translate C code into LLVM intermediate representation. LLVM itself optimizes that IR and emits (statically or at runtime) object code, C code, etc. An example of using LLVM to JIT C code can be found in this presentation by Nate Begeman: http://llvm.org/devmtg/2008-08/Begeman_EfficientJIT.pdf at the 2008 LLVM dev meeting. There is video linked off of this page as well: http://llvm.org/devmtg/2008-08/

There is less incentive to JIT languages like C because so much can be determined statically, unlike more dynamic languages. It can still buy you something if you use runtime specialization to e.g. make different, optimized versions of functions based on the values of the arguments.

C++ is more appropriate for JITing than C, especially if you do a lot of stuff with virtual methods. That said, the cost of a virtual method call is a lot less than a typical dynamic method invocation in a dynamic language, so the cost savings aren't as huge, except maybe in inner loops.

However, these days new C/C++ apps seem restricted to domains like embedded systems, real-time, and game development, where memory usage (no virtual memory) and performance consistency is very important. So a JIT doesn't make a lot of sense, as it introduces a lot of variability into the application.

"C++ is more appropriate for JITing than C" Agreed.

"However, these days new C/C++ apps seem restricted to domains like embedded systems, real-time, and game development, where memory usage (no virtual memory) and performance consistency is very important. So a JIT doesn't make a lot of sense, as it introduces a lot of variability into the application."

Probably also true, but a JIT can be useful for loading code at runtime and supporting a wide variety of hardware without shipping a fat binary with a bunch of different versions. Graphics drivers contain JITs for OpenGL/shader language code, and Apple uses LLVM JIT to generate optimized code from GLSL shaders that takes advantage of all available hardware capabilities without a sea of #ifdefs ( http://llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf ). Your point about memory usage and variability is well-taken though.

Dunno what the defaults are, but I'm fairly sure I've compiled C applications with JIT enabled.

I'm not sure what that would even mean. JIT is an optimization for virtual machines. It compiles VM code (such as Java bytecode) or interpreted code to machine code at runtime. C already compiles to machine code.

In order to do anything resembling JIT, you would have to insert a runtime where one does not already exist.

LLVM's compiler suite compiles C to LLVM bitcode, and the LLVM (low-level virtual machine) runs that code.

I don't think LLVM provides any such virtual machine, despite its name. It has a code generator, but no VM as such.

I'm almost positive that LLVM provides both. You always target LLVM bytecode with your frontend, but then you can choose either to:

- run the bytecode using the LLVM with or without JIT.

- compile the LLVM bytecode into x86 bytecode.

This is what clang does (afaik) and is a reasonably nice use case because you write a static language that targets LLVM bytecode and end with a fast program because LLVM will output optimized x86 binaries.

However, I'm pretty sure that the efforts like unladen swallow attempt to use the LLVM's virtual machine in the hope that it will become very fast as they optimize it (especially the JIT part).

Yeah, you just instantiate an ExecutionEngine and feed it your LLVM bytecode, and it'll give you back C function pointers that you can call. The ExecutionEngine is either a JIT (which'll compile your bytecode into native code and give you that back) or it's an interpreter (where the function pointer you get back is an entry point into the interpreter).

Ok, my mistake, sorry.

No, there isn't any support for that in the C frontends that use LLVM. They all generate direct assembly code. Feel free to look at the clang and gcc-llvm source to verify.

he's saying JITs are very hard to implement

Reply on news.ycombinator.com