3 ms·
>> It runs about five times slower than the equivalent program > I'd be interested in hearing more about how these were benchmarked. On my machine, they both ru
by simonz05 11y ago
>> It runs about five times slower than the equivalent program
> I'd be interested in hearing more about how these were benchmarked. On my machine, they both run in roughly the same time, with a degree of variance that makes them roughly equivalent. Some runs, the iterator version is faster.
It's common to forget to turn on optimizations, which _seriously_ impact Rust's runtimes, LLVM can do wonders here. Generally speaking, if iterators are slower than a loop, that's a bug.
In my novice benchmark I found similar results as OP.
running 6 tests
test for_range_100 ... bench: 89 ns/iter (+/- 2)
test for_range_1000 ... bench: 929 ns/iter (+/- 98)
test for_range_10000 ... bench: 8815 ns/iter (+/- 414)
test for_while_100 ... bench: 36 ns/iter (+/- 3)
test for_while_1000 ... bench: 294 ns/iter (+/- 27)
test for_while_10000 ... bench: 2768 ns/iter (+/- 268)
test result: ok. 0 passed; 0 failed; 0 ignored; 6 measured
https://gist.github.com/simonz05/afd76c549d6c8afb8081 https://gist.github.com/simonz05/afd76c549d6c8afb8081
- Jweb_Guru 11y agoThat is not the same test as the OP's. It's not even the same test between the two different algorithms, since you hide different information from LLVM under different circumstances. If you have to put `test::black_box` everywhere to get anything but zeroes, the only thing you can really conclude is that LLVM is better at optimizing than you are at writing microbenchmarks (I'll agree it can be frustrating at times).