> If one would do runtime JIT compilation with runtime statistical information, it could very well a speed improvement. Or you could just be wasting cycles on

> If one would do runtime JIT compilation with runtime statistical information, it could very well a speed improvement. Or you could just be wasting cycles on profiling overhead and recompiling things for no reason. > A JIT could compile several optimized versions for different argument types and choose the best fit one at compile time. That's... a compile time optimization. > A JIT could do inlining code based on statistical information and select at runtime optimized functions with additional inlining. Tracing is very close to self-modifying code. What happens when you redefine a function? What happens when you redefine a function at a breakpoint? There is a lot of runtime overhead (profiling, bookkeeping to back out of inlining) and it is very hard to debug. And it is never going to be as fast as static inlining and dispatching (sealing) at compile time. > A JIT could remove runtime dispatch for often used code parts and provide versions for that. That's what dispatch caching already does. I think you and other people in this thread bought into the marketing hype for 10 year old tracing JavaScript implementations and now think that "JIT" is some kind of magic runtime optimization. The optimizations are all orthogonal to JIT (in fact GNU Lightning does none of the ones you alluded to). Adding tracing to any of the existing Common Lisp implementations would be a huge waste of time when there are easier and more effective things that can be done (like say converting an existing implementation to use SSA). > Then basically most COMPILE implementations in Common Lisp implementations would be a JIT. Yes. > Is there anything that ECL's COMPILE function makes it special? ECL uses GCC. If you read the original question, this was asking about libgccjit.