Uhm, Common Lisp, where JIT is not only available but is also manageable: the programmer can decide what deserves to be compiled and what does not.
Besides run time, JIT is available also when the code is compiled or loaded for execution (i.e., do you have a compilation or loading speed-up in mind? no problem, you can also compile that speed-up into native machine code, and so ad infinitum...).
You can turn that off by setting or binding sb-ext:*evaluator-mode* to :interpret.
Also, on my machine, compiling the identity lambda form takes about 200 usec with (optimize (compilation-speed 3) (debug 0)). SBCL could use a faster JIT mode, perhaps at compilation-speed 3/speed 0. Perhaps there are some other internal special variables that could be tweaked to reduce compile time.
When calling EVAL it can be much faster to use the interpreter than to go through the compiler. This has bitten me in the past. A faster compiler would get around that.
One of the competing open Common Lisp implementations, CCL, has a much faster compiler (albeit one that produces worse code). This can be useful in development.
Compiling to bytecode is still compilation. An interpreter would operate directly on the S-expressions. Obviously, this makes some constructs (such as TAGBODY) very inefficient.
Comments
Uhm, Common Lisp, where JIT is not only available but is also manageable: the programmer can decide what deserves to be compiled and what does not.
Besides run time, JIT is available also when the code is compiled or loaded for execution (i.e., do you have a compilation or loading speed-up in mind? no problem, you can also compile that speed-up into native machine code, and so ad infinitum...).
Not in typical builds of SBCL: all code is compiled before evaluation.
You can turn that off by setting or binding sb-ext:*evaluator-mode* to :interpret.
Also, on my machine, compiling the identity lambda form takes about 200 usec with (optimize (compilation-speed 3) (debug 0)). SBCL could use a faster JIT mode, perhaps at compilation-speed 3/speed 0. Perhaps there are some other internal special variables that could be tweaked to reduce compile time.
Are you sure this is actually makes a difference in your build?
Mine doesn't have the SB-INTERPRETER package, so I doubt binding the variable has an effect.
When calling EVAL it can be much faster to use the interpreter than to go through the compiler. This has bitten me in the past. A faster compiler would get around that.
One of the competing open Common Lisp implementations, CCL, has a much faster compiler (albeit one that produces worse code). This can be useful in development.
Eval would count as JIT compilation though[0]
[0] https://www.sbcl.org/manual/#compiler-only-implementation
It depends on the implementation. CLISP compiles when it is told to.
Last I checked, CLISP compiles to byte code. Did they add a JITter for the byte code?
Compiling to bytecode is still compilation. An interpreter would operate directly on the S-expressions. Obviously, this makes some constructs (such as TAGBODY) very inefficient.
There is a jit branch, but not in master.
is an xtensa lx7 (esp32-s3) target available that does not use llvm?
I am told there is http://www.ulisp.com/show?2AJI Never used it myself; I cannot attest to the completeness of the implementation.