3 ms·

> SBCL has two interpreters, IIRC. You can configure SBCL to use an interpreter. SBCL's original "interpreter" is %simple-eval, which just calls the compiler.

> SBCL has two interpreters, IIRC. You can configure SBCL to use an interpreter. SBCL's original "interpreter" is %simple-eval, which just calls the compiler. SB!EVAL was added sometime around 2008, but as you point out it is not used unless you set evaluator-mode to something other than :compile. The default code path goes through %simple-eval and the compiler. I have been using SBCL since before SB!EVAL was added, and I have never used the interpreter. > ECL has three ways to run code: an interpreter, a byte code engine and a Lisp-to-C compiler The confusing thing about ECL is that someone decided to call their bytecode VM an "interpreter." ECL has no interpreter - eval_nontrivial_form just calls the bytecode compiler. All that is irrelevant to the fact that ECL uses GCC as a JIT. > In theory one could use a JIT to compile the byte codes to native code at runtime. Which would be completely pointless because GCC (or clang or MVCC, but the original question was about libgccjit) is already there and does better optimization. > Some experiments of improving CLOS speed at runtime (similar to what Julia does) might be considered to be a moral equivalent of a JIT Like half of the PCL is devoted to various kinds of caching that are in fact adaptive optimization. It is not a big step from that to inline caching. But again, why would you do that when you don't need to? https://github.com/guicho271828/inlined-generic-function https://github.com/guicho271828/inlined-generic-function https://github.com/marcoheisig/fast-generic-functions https://github.com/marcoheisig/fast-generic-functions There is a reason Mozilla went from tracing (TraceMonkey) to inline caching (JägerMonkey) to type specialization (IonMonkey). JavaScript JITs have moved closer to Lisp compilers, not vice-versa. I have covered other misconceptions that you have listed elsewhere in this thread.

lispm 5y ago
> and I have never used the interpreter There would only be a reason to use it, if it were providing added functionality. In SBCL I don't use the interpreter, but in other implementations I might use it, for example when a source stepper uses an interpreter. > ECL has no interpreter I missed that - actually ECL had an interpreter, but it was removed long time ago. > Which would be completely pointless because GCC (or clang or MVCC, but the original question was about libgccjit) is already there and does better optimization. That's not clear. If one would do runtime JIT compilation with runtime statistical information, it could very well a speed improvement. There are a bunch of things which could (!) be useful: Typically functions in Lisp have only one compiled version, depending on a fixed amount of declarations and optimization settings. A JIT could compile several optimized versions for different argument types and choose the best fit one at compile time. A JIT could do inlining code based on statistical information and select at runtime optimized functions with additional inlining. A JIT could remove runtime dispatch for often used code parts and provide versions for that. > PCL is devoted to various kinds of caching And a bunch of implementations were trying to make sure that no compilation takes place during CLOS calls -> thus making sure that a Lisp compiler at runtime is not necessary. > There is a reason Mozilla went from tracing (TraceMonkey) to inline caching (JägerMonkey) to type specialization (IonMonkey). JavaScript JITs have moved closer to Lisp compilers, not vice-versa. Lisp compilers are usually AOT native code generating compilers, like ECL's Lisp->C compiler. > I have covered other misconceptions that you have listed elsewhere in this thread. Like you claim that ECL's version of the Common Lisp COMPILE is a JIT. Then basically most COMPILE implementations in Common Lisp implementations would be a JIT. Is there anything that ECL's COMPILE function makes it special? Otherwise Lisp I of 1960 had a JIT. The function comdef (page 53 in the Lisp I Programmer's Manual) would compile named functions at runtime to machine code.
- sedachv 5y ago
  > 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.
  - deleted 5y ago
    [deleted]

lispm 5y ago

> and I have never used the interpreter There would only be a reason to use it, if it were providing added functionality. In SBCL I don't use the interpreter, but in other implementations I might use it, for example when a source stepper uses an interpreter. > ECL has no interpreter I missed that - actually ECL had an interpreter, but it was removed long time ago. > Which would be completely pointless because GCC (or clang or MVCC, but the original question was about libgccjit) is already there and does better optimization. That's not clear. If one would do runtime JIT compilation with runtime statistical information, it could very well a speed improvement. There are a bunch of things which could (!) be useful: Typically functions in Lisp have only one compiled version, depending on a fixed amount of declarations and optimization settings. A JIT could compile several optimized versions for different argument types and choose the best fit one at compile time. A JIT could do inlining code based on statistical information and select at runtime optimized functions with additional inlining. A JIT could remove runtime dispatch for often used code parts and provide versions for that. > PCL is devoted to various kinds of caching And a bunch of implementations were trying to make sure that no compilation takes place during CLOS calls -> thus making sure that a Lisp compiler at runtime is not necessary. > There is a reason Mozilla went from tracing (TraceMonkey) to inline caching (JägerMonkey) to type specialization (IonMonkey). JavaScript JITs have moved closer to Lisp compilers, not vice-versa. Lisp compilers are usually AOT native code generating compilers, like ECL's Lisp->C compiler. > I have covered other misconceptions that you have listed elsewhere in this thread. Like you claim that ECL's version of the Common Lisp COMPILE is a JIT. Then basically most COMPILE implementations in Common Lisp implementations would be a JIT. Is there anything that ECL's COMPILE function makes it special? Otherwise Lisp I of 1960 had a JIT. The function comdef (page 53 in the Lisp I Programmer's Manual) would compile named functions at runtime to machine code.

sedachv 5y ago
> 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.
- deleted 5y ago
  [deleted]