Benchmarking Rust with Project Euler Solutions(japaric.github.io)
japaric.github.io
Benchmarking Rust with Project Euler Solutions
http://japaric.github.io/eulermark.rs/002.html
4 comments
What's the reason for 'asm("");' in 002.c (and other c codes)? All I can see that doing is intentionally breaking the compiler's ability to optimize over loop iterations, which puts rust a huge advantage over c.
It's probably to avoid dead-code elimination, which would defeat the purpose of the benchmark. The rust benchmarks use test::black_box [0], which does the same thing, so there's no unfair advantage there.
[0]: http://doc.rust-lang.org/test/fn.black_box.html
[0]: http://doc.rust-lang.org/test/fn.black_box.html
But it appears that the Rust code is avoiding optimization over f() whereas for C code `asm("");` is inside iteration loop.
For this particular benchmark Rust is beating C and LuaJIT by an unbelievable margin. I emitted IR for the Rust code[1] and it contains 4613732, the result of function f.
[1] https://github.com/japaric/eulermark.rs/blob/master/problems...
[2] compilation flags used: rustc -O --emit ir 002.rs
[1] https://github.com/japaric/eulermark.rs/blob/master/problems...
[2] compilation flags used: rustc -O --emit ir 002.rs
This is one of the reasons microbenchmarks are really not particularly useful, especially when comparing two different languages. You have to intentionally cripple the optimizer in order to even get some of them to run the "actual" algorithm. And you have to restrict the algorithm used even if it might be impossible to implement the fastest algorithm as efficiently in one or more of the languages. You might argue that the point isn't to test the particular code, but the properties of the language and its optimizer. That's fair, but what about languages like Go that don't try to do constant folding like this in the name of fast compilation, or interpreted languages that don't perform JIT compilation? They are going to look unrealistically good on benchmarks like this compared to how similar routines would perform in an actual program.
I'd love to see this benchmark alongside how many lines of code were required in each language.
Another good reason to invest more in Rust!