Hello, I just had a random thought. If I want fast Rust compilation, using an interpreter might speed things up since it doesn't need to generate machine code. When I think about how fast JavaScript compiles, yup, it's because JS isn't compiled, it's interpreted, which is why running it in development is instant. Python and PHP are also interpreted, and they also run instantly during development. So I tried looking for a Rust interpreter, hoping to find something other than Miri. Turned out there isn't one. So I benchmarked cargo miri run and cargo run that uses Cranelift to see which one shows results in the terminal faster. For the benchmark, I edited the code, compiled it with cargo run, then edited the code again and used cargo miri run. The result? cargo miri run was way faster

Cargo run :

   Compiling tes v0.1.0 (/dev/tes)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.38s
     Running `target/debug/tes`
Hellobdkjsjtjo, world!

Cargo miri run :

   Compiling uwu v0.1.0 (/dev/tes)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running `/dev/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/tes`
Hellowshbsjjkjwjo, world!

That is 17x faster for incremental compilation, which is good fit for applications like GUIs where need to rerun frequently to see visual changes

But are there any specific gotchas that make cargo miri run unsuitable for hot reloading during development? Because it's a bit confusing why focus on Cranelift instead of an interpreter if the goal is fast development compilation? Is there an inherent issue with using an interpreter?

Aside from fast compilation, another good of the Miri interpreter is that it can detect undefined behavior while the code is running

I'm aware of cargo check for finding errors without running the code. But sometimes we actually need to run it, like when building a backend or a GUI

What do you guys think?

EDIT :

Just tried it on a medium sized backend project, and it failed due to an unsupported call. Is this an inherent limitation of interpreters in general, or is it a limitation specific to Miri as in it simply hasn't been implemented in Miri yet?

error: unsupported operation: can't call foreign function `socket` on OS `linux`
  --> /dev/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/mio-1.1.1/src/sys/unix/mod.rs:8:28
   |
 8 | ...unsafe { libc::$fn($($arg, )*) };
   |             ^^^^^^^^^^^^^^^^^^^^^ unsupported operation occurred here
   |
  ::: /dev/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/mio-1.1.1/src/sys/unix/net.rs:33:18
   |
33 | ... = syscall!(socket(domain, socket_type, 0))?;
   |       ---------------------------------------- in this macro invocation
   |
   = help: this means the program tried to do something Miri does not support; it does not indicate a bug in the program

10 posts - 3 participants

Read full topic