6 ms·

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

by glum64 26d ago

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

clbrmbr 26d ago
is an xtensa lx7 (esp32-s3) target available that does not use llvm?
- glum64 26d ago
  I am told there is http://www.ulisp.com/show?2AJI http://www.ulisp.com/show?2AJI Never used it myself; I cannot attest to the completeness of the implementation.
fweimer 26d ago
Not in typical builds of SBCL: all code is compiled before evaluation.
- glum64 26d ago
  It depends on the implementation. CLISP compiles when it is told to.
  - pfdietz 26d ago
    Last I checked, CLISP compiles to byte code. Did they add a JITter for the byte code?
    - fweimer 26d ago
      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.
    - rurban 25d ago
      There is a jit branch, but not in master.
- malisper 26d ago
  Eval would count as JIT compilation though[0] [0] https://www.sbcl.org/manual/#compiler-only-implementation https://www.sbcl.org/manual/#compiler-only-implementation
- pfdietz 26d ago
  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.
  - fweimer 26d ago
    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.
    - pfdietz 26d ago
      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.

by glum64 26d ago

clbrmbr 26d ago

is an xtensa lx7 (esp32-s3) target available that does not use llvm?

glum64 26d ago
I am told there is http://www.ulisp.com/show?2AJI http://www.ulisp.com/show?2AJI Never used it myself; I cannot attest to the completeness of the implementation.

fweimer 26d ago

Not in typical builds of SBCL: all code is compiled before evaluation.

glum64 26d ago
It depends on the implementation. CLISP compiles when it is told to.
- pfdietz 26d ago
  Last I checked, CLISP compiles to byte code. Did they add a JITter for the byte code?
  - fweimer 26d ago
    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.
  - rurban 25d ago
    There is a jit branch, but not in master.
malisper 26d ago
Eval would count as JIT compilation though[0] [0] https://www.sbcl.org/manual/#compiler-only-implementation https://www.sbcl.org/manual/#compiler-only-implementation
pfdietz 26d ago
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.
- fweimer 26d ago
  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.
  - pfdietz 26d ago
    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.