@oli @RalfJ is there a rough estimate of miri's slowdown factor that I can use as a rule of thumb?
other than "a lot"?^^
in https://github.com/rust-lang/miri/issues/638 someone reported "100x slower than python". I didn't verify that.
I once benchmarked against plain execution, and I think these benchmarks are even still around in our repo, so you can test how bad it is today, but it used to be quite a few orders of magnitude
with stacked borrows that probably got even worse :D
I hold out hope of running Miri on a testsuite driven by a property-based test suite
have you tried running miri on a quickcheck test suite?
we do have random number generators nowadays
to give you an idea: the libcore test suite takes 0.4s when running "for real" and 6:20 min when running in Miri
that's roughly 1000x slowdown
which is in the same ballpark as "100x slower than python" I guess ;)
uh, I wanted to test that with validation disabled but then in ICEs...^^
@oli quickcheck is old and busted. proptest is where it's at.
What's annoying is that the places I want to use it are probably the most Miri-difficult: FFI and SIMD
disabling validity is a roughly 2x speedup... as in, still 500x slower than "real"^^
yeah, SIMD needs someone to implement 5k intrinsics and FFI... I doubt will ever happen^^
I have twox-hash which uses proptest to validate the pure-Rust output against the C implementation. That's an "easy" property. Coming up with self contained properties is much harder.
I also have jetscii, which uses proptest to validate the SIMD output against the non-SIMD output.
In the first case, I don't want to run Miri on the FFI code.
Is there a way to annotate a function to have Miri not inspect within it?
"inspect within it"?
miri doesnt inspect anything, it evaluates
so it doesnt matter if there is FFI that is not used. but if your code runs FFI, there's nothing we can do.
cant you do the comparison "externally"? like, have the evaluation in Miri dump the results to a file and then compare that
that just requires disk I/O which is much more realistic than FFI ;)
I'm trying to think what the speed tradeoff would be there
Can I call
std::cmd::Process under Miri?
then I could run the FFI in another non-Miri process.
Realistically, I can just run the tests 2x: once with comparing against FFI and once with the comparison replaced by
true. Find bugs in the first run, UB in the second.
no. but that is possible in principle...
lots of work but not impossible
someone would have to add a shim for
popen I guess