3 ms·

Two people (you and moonchild) reply to my statement that ECL uses a C compiler as a JIT, and come to the exact opposite conclusions about what a JIT is. I thin

• aidenn0 5y ago
  If compilation is explicit, it's not a JIT. That's why I said SBCL's LOAD and REPL (which decides between interpreting and compiling) is arguably JIT. When you explicitly compile (e.g. via ASDF which separates the compile and load phase with FASLs between) in any lisp, that doesn't meet the bar for being a JIT anymore than a C program that distributes plugins as source and compiles them to load the .so is.
  • sedachv 5y ago
    > If compilation is explicit, it's not a JIT. You have machine code generation at run-time, you can then make arbitrary decisions for when to do the code generation. Explain how this is not a JavaScript JIT compiler when you run it in ECL: https://github.com/akapav/js/blob/master/js.lisp#L72 https://github.com/akapav/js/blob/master/js.lisp#L72 > That's why I said SBCL's LOAD and REPL (which decides between interpreting and compiling) is arguably JIT. SBCL does not really have an interpreter (it started out without any kind of interpreter at all), it only has a compiler. No wonder you misunderstood my point about SBCL. > that doesn't meet the bar for being a JIT anymore than a C program that distributes plugins as source and compiles them to load the .so is. Let's try to rephrase that a little bit: "that doesn't meet the bar for being a JIT anymore than a [web browser] program that distributes [loads] plugins [JavaScript] as source and compiles them to load the .so [machine code] is."
    • lispm 5y ago
      SBCL has two interpreters, IIRC. You can configure SBCL to use an interpreter. But neither SBCL nor ECL has a JIT. A JIT is a subsystem which on its own decides to compile an intermediate representation (usually some compiled byte code) to native code. Typically the JIT decides when and how to compile it, often using runtime information to compile runtime optimized code. In both SBCL and ECL, the Lisp is either configured to compile AOT or the user calls the compiler. If there is a source interpreter running the source, the user has to explicitly call COMPILE and COMPILE will not use any runtime information on its own - like using statistics how often functions are being use with which argument types and compile code versions for different argument types. It will also not compile new optimized versions on additional runtime information. The current Lisp compiler will only use the static information which is in the source. JIT systems OTOH watch the byte code execution and compile code on its own to optimized/native versions, based on the runtime information the JIT system observes. In basically most Common Lisp implementation, the decision to what kind of code and when it is compiled/executed is left to the user. Though I think there was a CLISP experiment with compiling CLISP byte codes to native with a JIT. https://sourceforge.net/p/clisp/mailman/clisp-devel/thread/e58c9f550801292304v5e097f5bw22b1abe65d49aeed%40mail.gmail.com/#msg18451246 https://sourceforge.net/p/clisp/mailman/clisp-devel/thread/e... ECL has three ways to run code: an interpreter, a byte code engine and a Lisp-to-C compiler (files, and incremental via files). In theory one could use a JIT to compile the byte codes to native code at runtime. I don't know if this has been tried. Some experiments of improving CLOS speed at runtime (similar to what Julia does) might be considered to be a moral equivalent of a JIT - but I haven't checked it out. https://github.com/numcl/specialized-function https://github.com/numcl/specialized-function
      • sedachv 5y ago
        > 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.