On: Python interpreter written in rust reaches 10000 c...

[__s]

https://github.com/RustPython/RustPython/tree/main/jit

Pretty sparse. Uses cranelift tho, which is what Firefox is using for wasm

For comparison, here's a complete JIT-for-befunge using cranelift: https://github.com/serprex/Befunge/blob/master/barfs/src/jit...

Rust is seeing ~5x improvement in compile time using cranelift for debug builds instead of llvm. Cranelift is much better suited as a jit library than llvm is. Bit of a pain postgres went the llvm route

[orra → __s]

> Cranelift is much better suited as a jit library than llvm is.

Unladen Swallow is seared in my mind. It was a failed project, back in 2009, to improve the speed of CPython by using LLVM as a JIT.

[aardvark179 → orra]

Was it really LLVM that was the problem, or the fact that there’s a lot more to making a dynamic language fast than compiling individual methods?

[orra → aardvark179]

Sure, making a dynamic language fast is not easy. However, back then people thought LLVM was a magic wand. It wasn't. There were several problems.

First, the Unladen Swallow team (IIRC) spent a lot of time fixing bugs in LLVM.

Second, LLVM isn't fast at compiling code, at least not for a JIT. This is legitimately surprising, because the official LLVM Tutorial implements a JIT.

Third, LLVM used to stand for Low Level Virtual Machine. I don't know when it stopped standing for that; clearly it hasn't for a long time. But with “Virtual Machine” in the title, you can see why people might have thought it would be suitable for implementing a dynamic language. cf. GraalVM these days.

[chrisseaton → aardvark179]

Exactly. LLVM and Cranelift are essentially code generation backends when you’re applying them for dynamic languages. You need an entire actual custom compiler in front of them to get good code out of them.

[skrtskrt → __s]

Sorry my limited understanding here, does having a JIT making having a REPL easier/more possible?

I have only developed in Python professionally, and when I play around in Go and Rust, I really miss the ability to sketch things out in an IPython session.

[__s → skrtskrt]

JIT can be considered an optimization. If you F12 in your browser you have a javascript REPL, no need to know about JIT or not

CPython doesn't have a JIT, it has an interpreter. So it spends a lot of time in this loop: https://github.com/python/cpython/blob/main/Python/ceval.c

But you still have a repl with pypy. The downsides of JIT is that compiling bytecode to assembly can take up time (hurting startup performance, but that can be mitigated by not applying jit aggressively) & some programs have very dynamic behavior which the JIT has to eventually give up on (& go back to interpreting) or run off some pathological performance cliff where it takes up a bunch of memory & runs 10x slower than interpreter

Ruby 3 introduced a jit to their reference implementation

[oldsecondhand → skrtskrt]

JIT will have no effect on "user" experience, it's all about performance. (Compiles the parts that run often.)