
Rust programs versus C++ g++ (by benchmark task performance) - jokoon
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp
======
steveklabnik
Someday, we will have stable SIMD and we’ll see several of the Rust numbers go
down even more.

~~~
igouy
Someday, we will have updated C++ programs and we'll see the C++ numbers go
down even more.

~~~
galangalalgol
Don't really need SIMD intrinsics or a new rust program. There are some bugs
that have been resolved in the new llvm that allow better auto vectorization.
Nightly rust let's you turn them on now I thinj, I'll have to go run it again
and see how it does. So a rebuild is all that is necessary. Also using autovec
instead of intrinsics makes it more portable. For instance when I rebuilt the
leading rust n-body and the leading c n-body rust won. That is because my
machine had avx and llvm was already doing enough autovec to make it faster
than the old intrinsics the c version had hardcoded. The machine for the game
does not have avx. Even on the same hardware autovec can be fast. The winner
is FORTRAN for n-body and it uses autovec not intrinsics. Ifort is an Intel
only compiler, but at least from atoms to the newest it will always compile
and be fast. It took advantage of my avx and still beat rust for instance.
Also the c and c++ n-body cheat by using a single precision float for the
inverse square so they can use the intrinsic for that. The output isn't
checked to enough precision to make it matter but it is still counter to the
spirit of the benchmark.

~~~
igouy
>> There are some bugs that have been resolved in the new llvm …

Cool.

>> Nightly rust let's you turn them on now I thinj …

When they reach Stable …

>> The output isn't checked to enough precision to …

Checked enough to have disallowed a new C++ program in the past few weeks ;-)

~~~
galangalalgol
I had last run this comparison with rust 1.15. I reran it with 1.22 and they
have added a few of the fixes. Unfortunately, none of them mattered for the
n-body solution I was using. What is more, it was more than 10% slower than
1.15. Not impressed. I keep saying I want to try out rust as a c++ replacement
where I work as soon as it settles down. I think that may he a while. The
problem is that the rapid changes in c++ are causing us problems too as far as
tool accreditation for safety and security. So a language that changes even
faster is a non starter. But the comparable performance and superior safety
guarantees is quite attractive in our case.

~~~
steveklabnik
A lot of this kind of thing is due to upgrading LLVM, which I'd imagine should
cause similar variance with clang, but maybe not!

