Searched the page for "Rust" which returned nothing... and the box labels are awkward. Why not label them conventionally?
You can see the data in https://benchmarksgame-team.pages.debian.net/benchmarksgame/... but it has no graphic comparison.
Rust is now overall faster than C in benchmarks
21–30 of 445 posts
Re: Rust is now overall faster than C in benchmarks
#22One of Rust's performance advantages is the compiler's ability to unambiguously determine memory aliasing. Aliasing is why many numeric kernels are written in Fortran, a much older language that also enforces strict aliasing as it simply doesn't allow overlapping references. There are probably others as well, but this is the advantage I'm familiar with. C's ambiguity makes it harder to achieve some optimizations that…
LLVM's support for this is bugged, so rust does not currently take (edit: full) advantage of it.
Does not fully take advantage of it.
Re: Rust is now overall faster than C in benchmarks
#23When Rust is faster than C in a benchmark in which C++ is also faster than C, I know I can safely ignore such benchmark.
C++ is faster than C now for most things because C++ enables many optimizations that are impractical in C.
Re: Rust is now overall faster than C in benchmarks
#24Re: Rust is now overall faster than C in benchmarks
#25One of Rust's performance advantages is the compiler's ability to unambiguously determine memory aliasing. Aliasing is why many numeric kernels are written in Fortran, a much older language that also enforces strict aliasing as it simply doesn't allow overlapping references. There are probably others as well, but this is the advantage I'm familiar with. C's ambiguity makes it harder to achieve some optimizations that…
LLVM's support for this is bugged, so rust does not currently take (edit: full) advantage of it.
Rust does not take full advantage of it; that is, &T will still get noalias, it's &mut T that's currently disabled.
The tracking bug is https://github.com/rust-lang/rust/issues/54878
Re: Rust is now overall faster than C in benchmarks
#26When Rust is faster than C in a benchmark in which C++ is also faster than C, I know I can safely ignore such benchmark.
[deleted]
Re: Rust is now overall faster than C in benchmarks
#27When Rust is faster than C in a benchmark in which C++ is also faster than C, I know I can safely ignore such benchmark.
[deleted]
Re: Rust is now overall faster than C in benchmarks
#28One of Rust's performance advantages is the compiler's ability to unambiguously determine memory aliasing. Aliasing is why many numeric kernels are written in Fortran, a much older language that also enforces strict aliasing as it simply doesn't allow overlapping references. There are probably others as well, but this is the advantage I'm familiar with. C's ambiguity makes it harder to achieve some optimizations that…
LLVM's support for this is bugged, so rust does not currently take (edit: full) advantage of it.
I really hope this gets fixed at some point, just because I'd like to see how much faster rust can get. In particular I wonder how much it would impact the compiler itself since it is also written in rust.
Re: Rust is now overall faster than C in benchmarks
#29Earlier quoted context omitted.
LLVM's support for this is bugged, so rust does not currently take (edit: full) advantage of it.
Rust does not take full advantage of it; that is, &T will still get noalias, it's &mut T that's currently disabled. The tracking bug is https://github.com/rust-lang/rust/issues/54878
Ah, my mistake. Thank you for the correction.
Re: Rust is now overall faster than C in benchmarks
#30One of Rust's performance advantages is the compiler's ability to unambiguously determine memory aliasing. Aliasing is why many numeric kernels are written in Fortran, a much older language that also enforces strict aliasing as it simply doesn't allow overlapping references. There are probably others as well, but this is the advantage I'm familiar with. C's ambiguity makes it harder to achieve some optimizations that…
Unfortunately that's only on paper due to LLVM issues.