5 ms·

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

by ori_b 17y ago

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)

sparky 17y ago
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 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/ 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.
- sshumaker 17y ago
  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.
  - sparky 17y ago
    "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 http://llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf ). Your point about memory usage and variability is well-taken though.
jrockway 17y ago
Dunno what the defaults are, but I'm fairly sure I've compiled C applications with JIT enabled.
- scott_s 17y ago
  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.
  - jrockway 17y ago
    LLVM's compiler suite compiles C to LLVM bitcode, and the LLVM (low-level virtual machine) runs that code.
    - foldr 17y ago
      I don't think LLVM provides any such virtual machine, despite its name. It has a code generator, but no VM as such.
      - maximilian 17y ago
        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).
        nostrademons 17y ago
        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).

by ori_b 17y ago

sparky 17y ago

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

sshumaker 17y ago
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.
- sparky 17y ago
  "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 http://llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf ). Your point about memory usage and variability is well-taken though.

jrockway 17y ago

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

scott_s 17y ago
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.
- jrockway 17y ago
  LLVM's compiler suite compiles C to LLVM bitcode, and the LLVM (low-level virtual machine) runs that code.
  - foldr 17y ago
    I don't think LLVM provides any such virtual machine, despite its name. It has a code generator, but no VM as such.
    - maximilian 17y ago
      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).
      - nostrademons 17y ago
        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).