3 ms·

Miri is not really meant for performance profiling; it runs on unoptimized MIR, which has very different performance from LLVM-optimized machine code.

LegionMammal978 4y ago
As a caveat, it can still be useful for profiling constant-evaluated code to improve compile time, since Miri is built on the same evaluator that the compiler uses.
ttfkam 4y ago
I don't understand why you felt the need to point this out when the linked article explicitly mentioned it. > Important note: Miri is not intended to accurately replicate optimized Rust runtime code. Optimizing for Miri can sometimes make your real code slower, and vice versa. It’s a helpful tool to guide your optimization, but you should always benchmark your changes with release builds, not with Miri.
- IshKebab 4y ago
  I think they undersell the difference. You'd be laughed out of the room if you profiled debug code.
- Tobu 4y ago
  The author was gently panned when this was originally posted on Reddit, and they added that note, but now that the article is being reposted uncritically where people may not know the difference, it's worth pointing out again. The way the author got a profile out of Miri is creative, but Miri was never a helpful guide for profiling, it seems that the second benchmark they used for confirmation was also unoptimised (run without --release which is a rookie mistake). Then they got wrong conclusions from flawed observations about the costs of abstractions like range.contains.
pornel 4y ago
This is really important. I think author found results surprising and unintuitive, because they've been looking at the wrong thing. Rust libraries are designed to be fast when optimized with LLVM. Rust has a lot of layers of abstractions, and they're zero cost only when everything is fully optimized. If you look at unoptimized miri execution, or insert code-level instrumentation that gets in the way of the optimizer, these aren't zero cost any more, and overheads add up where they normally don't exist.

LegionMammal978 4y ago

As a caveat, it can still be useful for profiling constant-evaluated code to improve compile time, since Miri is built on the same evaluator that the compiler uses.

ttfkam 4y ago

I don't understand why you felt the need to point this out when the linked article explicitly mentioned it. > Important note: Miri is not intended to accurately replicate optimized Rust runtime code. Optimizing for Miri can sometimes make your real code slower, and vice versa. It’s a helpful tool to guide your optimization, but you should always benchmark your changes with release builds, not with Miri.

IshKebab 4y ago
I think they undersell the difference. You'd be laughed out of the room if you profiled debug code.
Tobu 4y ago
The author was gently panned when this was originally posted on Reddit, and they added that note, but now that the article is being reposted uncritically where people may not know the difference, it's worth pointing out again. The way the author got a profile out of Miri is creative, but Miri was never a helpful guide for profiling, it seems that the second benchmark they used for confirmation was also unoptimised (run without --release which is a rookie mistake). Then they got wrong conclusions from flawed observations about the costs of abstractions like range.contains.

pornel 4y ago

This is really important. I think author found results surprising and unintuitive, because they've been looking at the wrong thing. Rust libraries are designed to be fast when optimized with LLVM. Rust has a lot of layers of abstractions, and they're zero cost only when everything is fully optimized. If you look at unoptimized miri execution, or insert code-level instrumentation that gets in the way of the optimizer, these aren't zero cost any more, and overheads add up where they normally don't exist.