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.
> 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.
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.
> 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]
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.
The incremental compilation step is just their name for the nanopass compilation (many small steps). The code you execute is static and won't change during the execution of the program (unless you redefine it using a repl).
Do we at least agree that Chez does not generate code at runtime? Because I am very certain it does not (I have spent a lot of time with the chez codebase)
If you still want to call it a JIT then every language that compiles code to an intermediate representation and then executes it is a JIT language,which means just about every friggin language.
I have also ported a non-trivial amount of code making use of rackets JIT optimizations (based on hot paths) to Chez and have spent a lot of time compensating for the lack of the same optimizations in Chez.
SBCL compiles code fast enough to not have a distinct compilation step for most software in a way similar to chez and no one would consider it a JIT.
Edit:
Let me quote Andy Keep (akeep on github. One of chez schemes developers):
Chez Scheme does compile at the REPL, but in general I would not call it a JIT compiler. It just compiles everything the same way regardless of if you are compiling it ahead of time or while you are running in an interactive session.
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.
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
You can implement a lambda style of programming in lua.
Im made a game for the spring engine, where i implemented a simple function to use anonymous functions.
Granted it doesent have the lazy computation of a pure functional implementation.
T= process(T,
function(element)
if type(element) == "number" then
return element
end
end
)
Hey, it looks like a lot of valid comments of yours are invisible to normal users because they (and you) are marked as 'dead' in the system. I've vouched for as many as seemed valid. You might want to message one of the mods to ask to be marked as undead, or something.
