Main bottlenecks for fast iteration speed are the backend (cranelift/llvm) and linking. I wonder if there can be a compilation mode where all Rust dependencies are compiled down to MIR, maybe with some optimizations, and executed like this? With shims between them and between "must compile" ffi stuff. Then in the final binary (even in wasm) include the interpreter? Not sure how Miri could relate to this, since it executes Mir too, but it also has lots of checks, which in part prevent us from using ffi with it.
Miri nowadays does experimentally support FFI on Linux.
Miri is not a tool to make anything "faster", so it's definitely a dead end here. A performance-oriented MIR interpreter would look very different.
I recall reading someone’s report that running in Miri did make their test running faster. I don’t have a link or any details, but I think I remember they had programs which took very few actual steps, so the interpreter overhead was smaller than the gain from skipping codegen.
That was probably our paper on Rustlantis, which generates straight-line code where loops are taken at most once. That's approximately 0% of real-world programs, so it's not very relevant.
2 Likes
How reasonable would it be to fork miri and rip out all the soundness stuff, intending to improve performance? I've never so much as looked at a single line of miri, so that question may be fundamentally flawed.
I think you'd be better off writing something new from scratch. Something like a bytecode interpreter or so.
1 Like
I remember seeing an experiment for supporting JIT compilation in the cranelift backend, I wonder what happened to it and how it would compare to a optimized MIR interpreter.
I ripped out the old implementation for that a while ago due to implementation issues. A couple weeks ago I started a new implementation as part of Improve `rustc_codegen_cranelift` performance - Rust Project Goals, but then got busy with work, so I haven't finished it enough to be able to benchmark it yet.
3 Likes