I have more faith in the evolution of rust than C++. C++ has a lot of backward compatibility pressure with large large companies. Rust is new and is already quite a good language.
He's referring to how the language and it's ecosystem will evolve from this point forward in comparison to the C++ ecosystem. In addition, the programs that are there should be just fine. There is a lot of room for advancing the Rust compiler to generate more efficient routines from the same code. The Rust compiler, after all, is not taking full advantage of all of the available compiler information. A significant volume of information is simply discarded at the moment. C++ compilers don't have the same degree of headroom for possible future optimizations.
I know; that was not what the comment he replied to was referring to.
The comment he replied to was referring to the actual much better performance of one of those C++ benchmarks game programs, contributed just 6 weeks ago.
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.
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.
10 comments
[ 4.6 ms ] story [ 40.1 ms ] threadI know; that was not what the comment he replied to was referring to.
The comment he replied to was referring to the actual much better performance of one of those C++ benchmarks game programs, contributed just 6 weeks ago.
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 ;-)