Rust 1.27 Released With SIMD Improvements

[phoronix]

Phoronix: Rust 1.27 Released With SIMD Improvements

Adding to the list of busy software releases today is the availability of Rust 1.27...

http://www.phoronix.com/scan.php?page=news_item&px=Rust-1.27-Released

[rene]

oh, well, 'cause compiling Rust from source is so much fun - that will be fun the next time I update Firefox: https://www.youtube.com/watch?v=zNipdcUh7ZE :-/

[jacob]

What language is better than Rust? Rust with SIMD support!!!

[ssokolow]

It'll be interesting to see what effect this has once people start submitting patches to the test cases on The Benchmarks Game. Lack of SIMD on stable channel has been claimed to be one of the biggest things keeping the Rust benchmarks from catching up to the C and C++ benchmarks for a long time.

(That said, not the only one. For example, there's also that the C and C++ benchmarks are compiled with GCC rather than LLVM Clang, so Rust is at a disadvantage from not having a frontend for GCC's slightly more powerful optimizers.)

[jacob]

It'll be interesting to see what effect this has once people start submitting patches to the test cases on The Benchmarks Game. Lack of SIMD on stable channel has been claimed to be one of the biggest things keeping the Rust benchmarks from catching up to the C and C++ benchmarks for a long time.

(That said, not the only one. For example, there's also that the C and C++ benchmarks are compiled with GCC rather than LLVM Clang, so Rust is at a disadvantage from not having a frontend for GCC's slightly more powerful optimizers.)

It depends on the benchmarks. True, LLVM is still trailing GCC in terms of optimisation, but when the same C/C++ benchmarks are compiled with Clang (which is based on LLVM), there is usually not much difference between those and Rust. Ultimately it comes down to how easy is it to write faster and better code in each language, and here Rust often (but not always) shines thanks to its heavy bias towards stack allocation, strong protection against memory leaks and its excellent support for parallelism.

[browseria]

oh, well, 'cause compiling Rust from source is so much fun - that will be fun the next time I update Firefox: https://www.youtube.com/watch?v=zNipdcUh7ZE :-/

It's so interesting that you singled out Rust/Cargo here...what are your thoughts regarding:

• Java/Maven/Ivy
• Groovy/Gradle/Grails
• Scala/sbt
• D/Dubs/packageD
• Go/Godep/Glide/Govendor
• OCaml/OPAM
• Haskell/Cabal
• .NET/Nuget
• Ruby/Gems
• Python/Pips
• JavaScript|EcmaScript/npm/yarn/bower

It seems to me your argument can be made about any major language invented after C! And is your primary concern that your distro-of-choice is no longer the canonical source of your dependencies? MITM attacks? Is your distro's tooling not susceptible to the same MITM techniques? Or something else?

Genuinely curious, but feel free to ignore.

[brrrrttttt]

It depends on the benchmarks. True, LLVM is still trailing GCC in terms of optimisation, but when the same C/C++ benchmarks are compiled with Clang (which is based on LLVM), there is usually not much difference between those and Rust. Ultimately it comes down to how easy is it to write faster and better code in each language, and here Rust often (but not always) shines thanks to its heavy bias towards stack allocation, strong protection against memory leaks and its excellent support for parallelism.

If I spend >90% of my (limited) time working on brown field projects written in C/C++/Go, it's unlikely I'm going to be as productive writing greenfield projects in Rust, so it's not really worth it for the small subset of bugs Rust can prevent. One day it will have the momentum to get past that, but that seems some way off yet.

[jacob]

If I spend >90% of my (limited) time working on brown field projects written in C/C++/Go, it's unlikely I'm going to be as productive writing greenfield projects in Rust, so it's not really worth it for the small subset of bugs Rust can prevent. One day it will have the momentum to get past that, but that seems some way off yet.

Momentum-wise, Rust is doing perfectly well I think. No-one says it's for everyone or that it's the silver bullet that solves all programming problems. If it doesn't give you benefits, you are not alone. If C/C++/Go works well for you, you have no reason to switch. Similarly, those who embraced Rust and make great stuff with it are not alone either. But I think you are wrong in assuming that Rust can only prevent "a small subset of bugs"; in fact, memory errors, buffer overflows and race conditions are endemic in C/C++ and even in Go. But Rust is not just about preventing, it's also about guarantees. It is also possible to write a memory-safe program in C++, but it's next to impossible to *prove* that it is memory safe. In Rust, the compiler does it for you for free.

[rubdos]

If I spend >90% of my (limited) time working on brown field projects written in C/C++/Go, it's unlikely I'm going to be as productive writing greenfield projects in Rust, so it's not really worth it for the small subset of bugs Rust can prevent. One day it will have the momentum to get past that, but that seems some way off yet.

I agree with jacob here, but would add one additional thing: it's not because today you are writing something in C/C++/Go, that tomorrow you won't have something that would be a better fit for Rust!

[rubdos]

I personally think that the cryptographic community will be loving this at some point. One library that comes to mind is curve25519-dalek (https://github.com/dalek-cryptography/curve25519-dalek) who merged experimental (AVX2) SIMD support 7 hours ago (https://github.com/dalek-cryptograph...dalek/pull/146), and are working on a NEON based back-end too (https://github.com/dalek-cryptograph...lek/issues/147).