Hacker News Reader

Comment by glum64 | Hacker News Reader

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

View on HN

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

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.

Eval would count as JIT compilation though[0]

[0] https://www.sbcl.org/manual/#compiler-only-implementation

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.

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.

Reply on news.ycombinator.com