Robert Clipsham: >This may be true, but the overhead of loading/setting up a JIT environment at >compile time will have a horrific effect on compile time for most D apps, it >will only show an advantage where there's a lot of CTFE used.<
A JIT that is not trash is able to start only when it is useful, that is when it is able to reduce the total running time, that is the compile time. I have seen that the Lua JIT 2.0a4 usually starts and does its work in tiny fractions of a second. The JIT based on LLVM is probably quite slower than the fabolous Lua JIT, but you can make it start only on CTFE that require more than 0.1 or 0.5 seconds to run (in practice you use the number of times a function gets called, etc). >Add to this it needs a complete rewrite of how CTFE is done,< Eventually this can be a good thing. It's the LLVM JIT/garbage collector that does lot of the work. >> With some more work you can also keep some parts of LLVM around at >> runtime, to use the compiler as a library at runtime, as C#4 does. > I seem to recall the benefit of runtime optimisation isn't that great, > have you got some evidence that shows otherwise? I think you have misquoted my post a bit: keeping the compiler as a library that can be used at runtime from normal D code is useful for example to implement an eval() that is able to compile functions or instantiate templates at runtime, to implement a shell that's able to run D commands interactively, to implement Lisp-style run-time macros, and so on and on. While keeping the compiler at runtime beside the program is something different, this isn't a compiler library that is meant to be used from D code, it's used by the runtime to perform optimizations and more. Runtime optimisation is very important (or even essential) if you want to perform good inlining of virtual functions (and probably delegates too), it's better than regular profile-guided optimization because you have real usage data while the program runs. Today Java code is sometimes even faster than C++ code just because of HotSpot, that performs optmizations at run-time. If you try to optimize Java code at compile-time you will probably not reach similar performance levels. So the benefits of runtime optimisation are great. If D will have success, in some years this will probably become the future of D compilation. As they say JIT compilers "have won". Bye, bearophile
