4 ms·
Thanks for the HN post! :) Rust, Go, and D language explorers are https://<lang>.godbolt.org https://<lang>.godbolt.org, e.g. https://rust.godbolt.org/ https:/
by mattgodbolt 11y ago
Thanks for the HN post! :)
Rust, Go, and D language explorers are https://<lang>.godbolt.org https://<lang>.godbolt.org, e.g. https://rust.godbolt.org/ https://rust.godbolt.org/ and so on
- nwmcsween 11y agoCan you get the weird go asm / ir rep of go from it?
- 672723074828 11y agoI wish that I could more easily compare the assembly outputs of the different compilers! Three or more of the rightmost panel would be superb! I want to see how the assembly compares between them without having to switch back and forth using the compiler dropdown! Make it so my good man! Make it so!
- mattgodbolt 11y agoThanks! It's a frequently requested feature but I've yet to find a decent way to present it. There's an issue tracker on GitHub that you're welcome to chime in on if you have ideas :)
- 672723074828 11y agoThis is very interesting! There is a huge difference between the assembly code generated by the C compilers and the assembly code generated by the Rust compiler for the equivalent code samples! Sometimes there is 10 to 20 times more lines of assembly generated for the Rust code than there is for the C code! The C assembly output is typically very tight while the Rust assembly output is much more verbose! Doesn't the much greater amount of Rust assembly code have a very negative impact on its performance? I just don't see how it can be claimed that Rust can be nearly as fast as C when executing the Rust assembly code requires so many times more instructions to be executed! I don't think it is a case of many fast instructions being chosen instead of a small number of less fast instructions. The Rust assembly to me just looks very unoptimized! I know Rust is a young language still but there is still a very big gap between the C assembly and the Rust assembly!
- dbaupp 11y ago> The Rust assembly to me just looks very unoptimized! If you're not adding a flag like `-C opt-level=3` to the compiler invocation this is literally true. (For one, Rust's unoptimised code does more work than C's, e.g. arithmetic operations are checked for overflow in debug mode, which is the default when optimisations are off, but is disabled when optimisations are on.) With optimisations on, Rust seems to do a better job, e.g. the loop in the max_array example is vectorised and unrolled by Rust, but not by gcc or clang.
- mattgodbolt 11y agoI posted an article on this pretty recently: with optimisation on, Rust is comparable to C++ : http://xania.org/201505/on-rust-performance http://xania.org/201505/on-rust-performance
- steveklabnik 11y ago> I just don't see how it can be claimed that Rust can be nearly as > fast as C when executing the Rust assembly code requires so many > times more instructions to be executed! Well, beyond what others have said here, with performance, it depends on the exact details. For example, our regex library has gotten some upgrades recently, and so on the benchmark game: * http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna * http://benchmarksgame.alioth.debian.org/u32/performance.php?test=regexdna * http://benchmarksgame.alioth.debian.org/u32q/performance.php?test=regexdna * http://benchmarksgame.alioth.debian.org/u64/performance.php?test=regexdna We're currently the fastest in two of them, and second place in two of them, once to C. But in many of the other benchmarks, we're slower. At best, a claim like "Rust is as nearly as fast as C" can only be said for broad categories of things. The devil is in the details.