10 ms·

Is there any flavor of lisp that is close to luajit performances and still small?

deleted 9y ago
[deleted]
shakna 9y ago
Gambit-C [0]. It's a R5RS Scheme, and is near-C level of performance. It compiles to C, so embedding it is fairly easy too. Compiles to static executables, which is easy for distribution. Chez Scheme [1]. It's a R6RS Scheme, so bigger, but Chez has much better embedding support, is backed by Cisco instead of a single dev. Chez doesn't make standalone executables though, because Chez is jitted. It may be the fastest Scheme. It also includes a compiler, a profiler, a great debugger, live memory-introspection, and an enhanced REPL [2] that can dump out it's definitions and any comments into a lovely Scheme file. [0] https://github.com/gambit/gambit https://github.com/gambit/gambit [1] https://github.com/cisco/ChezScheme https://github.com/cisco/ChezScheme [2] https://cisco.github.io/ChezScheme/csug9.5/use.html#./use:h2 https://cisco.github.io/ChezScheme/csug9.5/use.html#./use:h2
- bjoli 9y ago
  Chez is not JITted. Chez compiles to native binaries that run win the chez runtime (so not stand-alone).
  - shakna 9y ago
    > Source code is compiled on-the-fly when loaded from a source file or entered via the shell.[0] > Whether compiling on the fly or precompiling, the compiler produces optimized machine code, with some optimization across separately compiled library boundaries. [0] > Chez Scheme compiles source forms as it sees them to machine code before evaluating them, i.e., "just in time." [1] Chez can both JIT and pre-compile. But it absolutely has a JIT, and has had as far back as I could trace. [0] https://cisco.github.io/ChezScheme/ https://cisco.github.io/ChezScheme/ [1] https://www.scheme.com/csug8/use.html https://www.scheme.com/csug8/use.html
    - bjoli 9y ago
      Well, sure, but it is not what we mostly consider a JIT. The "JIT" part is just an AOT compile at runtime, without most of the nice things that we generally consider being a JIT. Take a hypothetical example: (for ([i (in-range a b c)]) (display i)). At compile time, chez has no way to know whether c is positive or negative (if it is set at runtime), thus making each iteration check whether c is positive or negative. In racket such code has negligible performance impact because the runtime will generate native code "just in time" with optimizations deduced from run-time information. The JIT of chez is just a side effect of the AOT being fast enough to run on the fly. SBCL does the same.
      - shakna 9y ago
        > Well, sure, but it is not what we mostly consider a JIT. The "JIT" part is just an AOT compile at runtime, without most of the nice things that we generally consider being a JIT. Huh? Then what do you consider a JIT? > In computing, just-in-time (JIT) compilation, also known as dynamic translation, is a way of executing computer code that involves compilation during execution of a program – at run time – rather than prior to execution. Most often, this consists of source code or more commonly bytecode translation to machine code, which is then executed directly. [0] [0] https://en.wikipedia.org/wiki/Just-in-time_compilation https://en.wikipedia.org/wiki/Just-in-time_compilation
        bjoli 9y ago
        The Wikipedia page supports my view. Chez compiles all code prior to execution and does not do any dynamic code generation during runtime. It is just fast enough that AOT compilation isn't a noticeable delay even at the repl.
        shakna 9y ago
        I'm not understanding you. Cisco says Chez compiles code just before it uses it, at runtime: > Chez Scheme compiles source forms as it sees them to machine code before evaluating them, i.e., "just in time." They refer to it as a "incremental native compiler". Incremental compilation happens at runtime. An incremental compiler that runs at runtime is a form of JIT compiler. > JIT compilation is a combination of the two traditional approaches to translation to machine code – ahead-of-time compilation (AOT), and interpretation – and combines some advantages and drawbacks of both Everything I know and Wiki says that is a JIT. Are you saying it isn't a JIT because it isn't a tracing JIT? Bearing in mind tracing JITs came about in the 70s, but JITs themselves are about a decade older.
- onefortheroad 9y ago
  Question: Could a algorithm in scheme handling anonymous data handed to it by lambda predecessor functions traverse this process backwards- and create cache optimal objects.. that is structures that contain all needed data in the biggest possible density (no dead weight as it is usual in oo-objects) Because if thats the case- and you put your data out- in a sort of masked union of the input data, you could create a nearly cach-miss free algorithm. Which should outperform everything except assembler altered C..
JohnStrangeII 9y ago
Chez scheme is extremely fast.
- bjoli 9y ago
  But a lot bigger than LuaJIT, and probably not as fast.
  - shakna 9y ago
    They're pretty comparable, performance wise, actually. Both are generally close to C speeds.
    - bjoli 9y ago
      Not in my experince. optimized chez (optimize-level 3) where I have spent quite some time optimizing the code, is generally within 2-5x of optimized C. I have found LuaJIT to be about that fast as well, but with quite a lot of exceptions where it is within 1.5x of C. I would say it is still the fastest dynamic language implementation. The work done by the racket7 folks on Chez might change that though. I have been reading Gustavo Massas patches to chez, and he is a pretty bright guy :D
bjoli 9y ago
Guile is the one I would embed, but it's speed is not yet on par with LuaJIT (and probably never will be, since LuaJIT is in a class of it's own). Guile3 will probably be one of the faster schemes since they are implementing native compilation, but that is still some years away. It is nice to embed though, and is a lot faster than python for things that isn't only using python things that are implemented in c.

deleted 9y ago

[deleted]

Gambit-C [0]. It's a R5RS Scheme, and is near-C level of performance. It compiles to C, so embedding it is fairly easy too. Compiles to static executables, which is easy for distribution. Chez Scheme [1]. It's a R6RS Scheme, so bigger, but Chez has much better embedding support, is backed by Cisco instead of a single dev. Chez doesn't make standalone executables though, because Chez is jitted. It may be the fastest Scheme. It also includes a compiler, a profiler, a great debugger, live memory-introspection, and an enhanced REPL [2] that can dump out it's definitions and any comments into a lovely Scheme file. [0] https://github.com/gambit/gambit https://github.com/gambit/gambit [1] https://github.com/cisco/ChezScheme https://github.com/cisco/ChezScheme [2] https://cisco.github.io/ChezScheme/csug9.5/use.html#./use:h2 https://cisco.github.io/ChezScheme/csug9.5/use.html#./use:h2

bjoli 9y ago
Chez is not JITted. Chez compiles to native binaries that run win the chez runtime (so not stand-alone).
- shakna 9y ago
  > Source code is compiled on-the-fly when loaded from a source file or entered via the shell.[0] > Whether compiling on the fly or precompiling, the compiler produces optimized machine code, with some optimization across separately compiled library boundaries. [0] > Chez Scheme compiles source forms as it sees them to machine code before evaluating them, i.e., "just in time." [1] Chez can both JIT and pre-compile. But it absolutely has a JIT, and has had as far back as I could trace. [0] https://cisco.github.io/ChezScheme/ https://cisco.github.io/ChezScheme/ [1] https://www.scheme.com/csug8/use.html https://www.scheme.com/csug8/use.html
  - bjoli 9y ago
    Well, sure, but it is not what we mostly consider a JIT. The "JIT" part is just an AOT compile at runtime, without most of the nice things that we generally consider being a JIT. Take a hypothetical example: (for ([i (in-range a b c)]) (display i)). At compile time, chez has no way to know whether c is positive or negative (if it is set at runtime), thus making each iteration check whether c is positive or negative. In racket such code has negligible performance impact because the runtime will generate native code "just in time" with optimizations deduced from run-time information. The JIT of chez is just a side effect of the AOT being fast enough to run on the fly. SBCL does the same.
    - shakna 9y ago
      > Well, sure, but it is not what we mostly consider a JIT. The "JIT" part is just an AOT compile at runtime, without most of the nice things that we generally consider being a JIT. Huh? Then what do you consider a JIT? > In computing, just-in-time (JIT) compilation, also known as dynamic translation, is a way of executing computer code that involves compilation during execution of a program – at run time – rather than prior to execution. Most often, this consists of source code or more commonly bytecode translation to machine code, which is then executed directly. [0] [0] https://en.wikipedia.org/wiki/Just-in-time_compilation https://en.wikipedia.org/wiki/Just-in-time_compilation
      - bjoli 9y ago
        The Wikipedia page supports my view. Chez compiles all code prior to execution and does not do any dynamic code generation during runtime. It is just fast enough that AOT compilation isn't a noticeable delay even at the repl.
        shakna 9y ago
        I'm not understanding you. Cisco says Chez compiles code just before it uses it, at runtime: > Chez Scheme compiles source forms as it sees them to machine code before evaluating them, i.e., "just in time." They refer to it as a "incremental native compiler". Incremental compilation happens at runtime. An incremental compiler that runs at runtime is a form of JIT compiler. > JIT compilation is a combination of the two traditional approaches to translation to machine code – ahead-of-time compilation (AOT), and interpretation – and combines some advantages and drawbacks of both Everything I know and Wiki says that is a JIT. Are you saying it isn't a JIT because it isn't a tracing JIT? Bearing in mind tracing JITs came about in the 70s, but JITs themselves are about a decade older.
onefortheroad 9y ago
Question: Could a algorithm in scheme handling anonymous data handed to it by lambda predecessor functions traverse this process backwards- and create cache optimal objects.. that is structures that contain all needed data in the biggest possible density (no dead weight as it is usual in oo-objects) Because if thats the case- and you put your data out- in a sort of masked union of the input data, you could create a nearly cach-miss free algorithm. Which should outperform everything except assembler altered C..

JohnStrangeII 9y ago

Chez scheme is extremely fast.

bjoli 9y ago
But a lot bigger than LuaJIT, and probably not as fast.
- shakna 9y ago
  They're pretty comparable, performance wise, actually. Both are generally close to C speeds.
  - bjoli 9y ago
    Not in my experince. optimized chez (optimize-level 3) where I have spent quite some time optimizing the code, is generally within 2-5x of optimized C. I have found LuaJIT to be about that fast as well, but with quite a lot of exceptions where it is within 1.5x of C. I would say it is still the fastest dynamic language implementation. The work done by the racket7 folks on Chez might change that though. I have been reading Gustavo Massas patches to chez, and he is a pretty bright guy :D

bjoli 9y ago

Guile is the one I would embed, but it's speed is not yet on par with LuaJIT (and probably never will be, since LuaJIT is in a class of it's own). Guile3 will probably be one of the faster schemes since they are implementing native compilation, but that is still some years away. It is nice to embed though, and is a lot faster than python for things that isn't only using python things that are implemented in c.