News for hackers. Stuff that matters.
Re:Rust programs versus C++ g++ (by benchmark task performance) by galangalalgol on Wednesday December 13, 2017 @08:47AM (#15914137)
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.
Re:Rust programs versus C++ g++ (by benchmark task performance) by igouy on Wednesday December 13, 2017 @10:52AM (#15914984)
>> 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 ;-)

Re:Rust programs versus C++ g++ (by benchmark task performance) by galangalalgol on Thursday December 14, 2017 @08:05AM (#15921931)
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.
Re:Rust programs versus C++ g++ (by benchmark task performance) by steveklabnik on Thursday December 14, 2017 @08:49AM (#15922197)
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!