
Interactive C++ Assembly Explorer - santaclaus
https://gcc.godbolt.org
======
mattgodbolt
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

~~~
672723074828
This 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
_> 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.

