Why does cargo miri test run sequentially on a single thread?

[Voultapher]

Unless I'm doing something wrong, why is the miri test runner not running the tests in parallel? I have a project that would greatly benefit from this.

[bjorn3]

When using cargo miri test the test harness is interpreted by miri itself. Miri can't run multiple interpreted threads at the same time. It has to switch between them inside the same OS thread. The fast majority of rustc can't be accessed from multiple threads and every MIR statement and terminator miri evaluates calls back into these non-thread safe parts of rustc several times. There is a project ongoing to allow rustc to work with multiple threads, but even then various data structures of miri itself likely don't like accesses from multiple threads at the same time.

[Voultapher]

Ok, thanks for the info. What about forking?

[Voultapher]

Because if I have to wait 2+ seconds per test, forking will certainly be worth it.

[bjorn3]

The test harness supports running tests in subprocesses when using -Zpanic-abort-tests -Cpanic=abort. However miri itself doesn't support this. For running regular processes it may not be too hard (assuming posix_spawn is used instead of fork+exec), but spawning the test process again would require for miri to detect this somehow and intercept it to run the test crate in miri again. This would mean that the test crate is recompiled for every test though unless the test harness is modified to reuse the process for the next test. As for forking the miri process, that is not possible in a safe way. After a fork basically the only thing you can do is exec and preparing state for the exec unless you do it very close to the start of the process such that you know for sure no background threads have been spawned. In case of rustc and thus miri one of the first things that happens is spawning a new thread to run the rest of the compilation on.

[bjorn3]

Maybe a wrapper around cargo miri test could be written which lists all tests and then spawns a couple of cargo miri test processes with each the test list filtered such that they all execute equal parts of the test suite?

[saethlin]

If you have nextest installed, we specifically support cargo miri nextest run in order to support running tests in parallel. The nextest model is process-based, it executes cargo miri test once to list all the tests then launches many cargo miri test processes in parallel, each selecting a single test to run.

But I think currently, cargo miri nextest run defaults to one job, so you'd need to run cargo miri nextest run -j32 for example.

[Voultapher]

Wow that's exactly what I was looking for 5min -> 25 seconds.

[RalfJung]

Could be worth adding a section on nextest to our readme?

[saethlin]

#2811