4 ms·

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 r

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

by sparky 17y ago

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.