6 ms·

> you wouldn't want to actually use that for any of the same cases as a traditional jit Well the most high-profile project using libgccjit right now is Elisp (

> you wouldn't want to actually use that for any of the same cases as a traditional jit Well the most high-profile project using libgccjit right now is Elisp (feature/native-comp GNU Emacs branch, which by all indications will eventually make it into the official release), and using GCC as a JIT compiler is how Embeddable Common Lisp has always worked.

aidenn0 5y ago
I don't think ECL uses GCC as a JIT; most common lisps use an incremental AOT compiler, which is different. ECL also has an interpreter, but I'm pretty sure it doesn't use GCC.
- sedachv 5y ago
  > I don't think ECL uses GCC as a JIT; most common lisps use an incremental AOT compiler, which is different https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop/src/cmp/cmpmain.lsp#L732 https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop... What is the difference?
  - aidenn0 5y ago
    A JIT compiles as the code is run, while an AOT compiler compiles before the code is run: (compile (lambda (x) x)) Compiles the lambda immediately. [edit] https://en.wikipedia.org/wiki/Dynamic_compilation https://en.wikipedia.org/wiki/Dynamic_compilation discusses Dynamic Compilation vs Incremental Compilation.
    - sedachv 5y ago
      > A JIT compiles as the code is run, while an AOT compiler compiles before the code is run By that definition using the REPL or loading source files in SBCL qualifies as a JIT. > https://en.wikipedia.org/wiki/Dynamic_compilation https://en.wikipedia.org/wiki/Dynamic_compilation discusses Dynamic Compilation vs Incremental Compilation. That article just seems to perpetuate the confusion: "Runtime environments using dynamic compilation typically have programs run slowly for the first few minutes, and then after that, most of the compilation and recompilation is done and it runs quickly." This could be talking about adaptive optimization, or dynamic recompilation, or even dispatch caching. You can do adaptive optimization in an interpreter or bytecode VM. Dispatch caching does not involve anything that looks like a compiler at all unless you are doing inlining. Most importantly, none of those things is what GNU Lightning or libgccjit does. All they do is generate machine code, at run-time. That is what a JIT is.
      - aidenn0 5y ago
        > By that definition using the REPL or loading source files in SBCL qualifies as a JIT. When SBCL compiles rather than interprets at the REPL, that arguably qualifies as a JIT. Same for loading top-level forms that aren't DEFUN. I'm pretty sure that ECL uses an interpreter in those cases though.
        sedachv 5y ago
        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 think people are really confused about this topic. Again, look at the code and explain how that is not JIT: https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop/src/cmp/cmpmain.lsp#L732 https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop...
        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."
moonchild 5y ago
Most of the elisp code you run is largely static. It does change, but only gradually; when you update a package, or make a small tweak to your config, you only have to recompile a few files. The elisp isn't being JITed, it's being compiled into shared objects which are cached aggressively. Completely different kettle of fish. > Embeddable Common Lisp ECL compiles to c.
- sedachv 5y ago
  > Most of the elisp code you run is largely static. It does change And JavaScript programs almost never change after a website is loaded. That has nothing to do with whether the programs are compiled. > you only have to recompile a few files. The elisp isn't being JITed, it's being compiled into shared objects which are cached aggressively You do not need any files to compile Elisp code, and you do not have to save the bytecode anywhere. > Completely different kettle of fish. What exactly is your definition of JIT? I think you might be confusing "JIT" with dynamic recompilation. > ECL compiles to c. Ok, and what do you think happens to C?
  - moonchild 5y ago
    >> Most of the elisp code you run is largely static. It does change > And JavaScript programs almost never change after a website is loaded No, but new javascript programs are frequently loaded. > You do not need any files to compile Elisp code, and you do not have to save the bytecode anywhere. You do not need to do any of this by hand, but it still happens; emacs does it automatically. > What exactly is your definition of JIT? I think you might be confusing "JIT" with dynamic recompilation. The term is somewhat nebulous. I don't think it's appropriate to apply it to the result of a traditional compilation process that occurs immediately prior to execution. If (for instance) I write a script in c and run it with tcc -run, what happens is that that file is compiled—very similarly to a ‘traditional’ AOT, though the dynamic linker is bypassed—and the result is run. Essential to JIT, in my view, is not dynamic recompilation, but plain dynamic compilation. Compilation should occur concurrently with execution, and is usually accompanied by some heuristic for deciding what to compile first (e.g. tracing) as well as an interpreter. Wikipedia agrees: > JIT is a way of executing computer code that involves compilation during execution of a program ______________________________________ > what do you think happens to C? Under most implementations, it is statically compiled to a native binary. Even if it is not, however, ECL does not JIT c, but produces it statically.

aidenn0 5y ago

I don't think ECL uses GCC as a JIT; most common lisps use an incremental AOT compiler, which is different. ECL also has an interpreter, but I'm pretty sure it doesn't use GCC.

sedachv 5y ago
> I don't think ECL uses GCC as a JIT; most common lisps use an incremental AOT compiler, which is different https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop/src/cmp/cmpmain.lsp#L732 https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop... What is the difference?
- aidenn0 5y ago
  A JIT compiles as the code is run, while an AOT compiler compiles before the code is run: (compile (lambda (x) x)) Compiles the lambda immediately. [edit] https://en.wikipedia.org/wiki/Dynamic_compilation https://en.wikipedia.org/wiki/Dynamic_compilation discusses Dynamic Compilation vs Incremental Compilation.
  - sedachv 5y ago
    > A JIT compiles as the code is run, while an AOT compiler compiles before the code is run By that definition using the REPL or loading source files in SBCL qualifies as a JIT. > https://en.wikipedia.org/wiki/Dynamic_compilation https://en.wikipedia.org/wiki/Dynamic_compilation discusses Dynamic Compilation vs Incremental Compilation. That article just seems to perpetuate the confusion: "Runtime environments using dynamic compilation typically have programs run slowly for the first few minutes, and then after that, most of the compilation and recompilation is done and it runs quickly." This could be talking about adaptive optimization, or dynamic recompilation, or even dispatch caching. You can do adaptive optimization in an interpreter or bytecode VM. Dispatch caching does not involve anything that looks like a compiler at all unless you are doing inlining. Most importantly, none of those things is what GNU Lightning or libgccjit does. All they do is generate machine code, at run-time. That is what a JIT is.
    - aidenn0 5y ago
      > By that definition using the REPL or loading source files in SBCL qualifies as a JIT. When SBCL compiles rather than interprets at the REPL, that arguably qualifies as a JIT. Same for loading top-level forms that aren't DEFUN. I'm pretty sure that ECL uses an interpreter in those cases though.
      - sedachv 5y ago
        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 think people are really confused about this topic. Again, look at the code and explain how that is not JIT: https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop/src/cmp/cmpmain.lsp#L732 https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop...
        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."

moonchild 5y ago

Most of the elisp code you run is largely static. It does change, but only gradually; when you update a package, or make a small tweak to your config, you only have to recompile a few files. The elisp isn't being JITed, it's being compiled into shared objects which are cached aggressively. Completely different kettle of fish. > Embeddable Common Lisp ECL compiles to c.

sedachv 5y ago
> Most of the elisp code you run is largely static. It does change And JavaScript programs almost never change after a website is loaded. That has nothing to do with whether the programs are compiled. > you only have to recompile a few files. The elisp isn't being JITed, it's being compiled into shared objects which are cached aggressively You do not need any files to compile Elisp code, and you do not have to save the bytecode anywhere. > Completely different kettle of fish. What exactly is your definition of JIT? I think you might be confusing "JIT" with dynamic recompilation. > ECL compiles to c. Ok, and what do you think happens to C?
- moonchild 5y ago
  >> Most of the elisp code you run is largely static. It does change > And JavaScript programs almost never change after a website is loaded No, but new javascript programs are frequently loaded. > You do not need any files to compile Elisp code, and you do not have to save the bytecode anywhere. You do not need to do any of this by hand, but it still happens; emacs does it automatically. > What exactly is your definition of JIT? I think you might be confusing "JIT" with dynamic recompilation. The term is somewhat nebulous. I don't think it's appropriate to apply it to the result of a traditional compilation process that occurs immediately prior to execution. If (for instance) I write a script in c and run it with tcc -run, what happens is that that file is compiled—very similarly to a ‘traditional’ AOT, though the dynamic linker is bypassed—and the result is run. Essential to JIT, in my view, is not dynamic recompilation, but plain dynamic compilation. Compilation should occur concurrently with execution, and is usually accompanied by some heuristic for deciding what to compile first (e.g. tracing) as well as an interpreter. Wikipedia agrees: > JIT is a way of executing computer code that involves compilation during execution of a program ______________________________________ > what do you think happens to C? Under most implementations, it is statically compiled to a native binary. Even if it is not, however, ECL does not JIT c, but produces it statically.