6 ms·

In general Rust is fast but slower then C: "Rust is safe indeed but, unfortunately, far from fast. By the moment of writing this article, it is comparable to Ja

In general Rust is fast but slower then C: "Rust is safe indeed but, unfortunately, far from fast. By the moment of writing this article, it is comparable to Java, Go, and Haskell regarding performance" http://www.viva64.com/en/b/0324/ http://www.viva64.com/en/b/0324/

pshc 11y ago
Wow, the article you linked is being defensive about something.
- MichaelGG 11y ago
  And since it was published, Rust is now in second place in that benchmark game graph: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
  - llogiq 11y ago
    Yeah, but that's only because teXitoi's and Joshua Landau's improvements to many Rust benchmarks are still open on the tracker. And it's still using 1.3 (Ok, 1.4 only came out yesterday). Note that this is not meant as an indictment of the maintainer, who is indeed working very hard to keep the site usable, accurate and useful.
    - igouy 11y ago
      >>(Ok, 1.4 only came out yesterday).<< Using 1.4 since 3pm PDT yesterday.
vardump 11y ago
I think good support for SIMD will go a long way. C++ is also pretty slow on its own, but with SIMD intrinsics (or lucky autovectorization [1]) it can be speedy. We're talking typically about 1.5 - 10x speedup in performance sensitive code with SIMD vs plain C++. Highest speedup I've seen was about 40x in sorting code. SIMD is a sorting demon. That said, I want safety more than speed. Speed I can get by writing an unsafe extension in C/C++. Safety is very hard to achieve in C/C++. Getting it right is the first priority. That's why I see Rust being used instead of where traditionally C++ is the default. Or some other new language that can fill C++'s shoes. Rust does seem like the strongest candidate at this point. I'm confident Rust and Golang performance will improve as the projects get more mature. The generated code is full of optimization opportunities. [1]: Autovectorization optimizations by C++ compilers tend to be fragile, small changes will undo them. So far easier to use intrinsics than figure out the black magic for autovectorization optimizations.
- kibwen 11y ago
  Note that SIMD support is currently in the Rust nightlies (as a result of Huon Wilson's summer internship at Mozilla), though I don't know what the timeline is for exposing that support in a stable release.
EugeneOZ 11y ago
Please don't quote this piece of shit. Seller of C++ tool trying to say "use C++ instead of Rust".
yokohummer7 11y ago
Please not this again. The article you mentioned is incorrect in many places, and was heavily criticized in various communities.[1][2] It doesn't qualify as a valid criticism. It is rather a badly written static analyzer promotion. Also, microbenchmarks are usually not very good at representing the real world characteristics. But then again, please look at the current version of the linked benchmark.[3] Rust now positions itself in the second place, thanks to the recent improvements given to the Rust programs used in the benchmarks. I believe Rust isn't as fast as highly optimized C, but I think it is safe to say that Rust is just as fast as C++, and both Rust and C++ are much faster than GC'ed languages such as Java, Haskell, and Go. Edit: I would even say that if Rust's performance is comparable to GC'ed languages, there's no point in using Rust in the first place. Rust is paying a lot of complexity to achieve memory safety without relying on garbage collection. [1] https://news.ycombinator.com/item?id=9531822 https://news.ycombinator.com/item?id=9531822 [2] https://www.reddit.com/r/cpp/comments/35pn6h/criticizing_the_rust_language_and_why_cc_will/cr6o9tz https://www.reddit.com/r/cpp/comments/35pn6h/criticizing_the... [3] http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
- johncolanduoni 11y ago
  > Edit: I would even say that if Rust's performance is comparable to GC'ed languages, there's no point in using Rust in the first place. Rust is paying a lot of complexity to achieve memory safety without relying on garbage collection. Rust has a lot of nice safety features not related to memory management that I'd love to see even in a language with GC. On top of the obvious lack of data races, linear types and borrowing are great for ensuring other kinds of sanity like preventing you from mutating a collection while you iterate over it.
  - Gankro 11y ago
    Technically Rust doesn't have proper linear typing, only affine typing. Destructors give you "basically" linear typing, but there's ways to bypass destructors both explicitly and accidentally (though if memory safety isn't at stake, this isn't a worth worrying about IMO): https://doc.rust-lang.org/nomicon/leaking.html https://doc.rust-lang.org/nomicon/leaking.html

pshc 11y ago

Wow, the article you linked is being defensive about something.

MichaelGG 11y ago
And since it was published, Rust is now in second place in that benchmark game graph: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
- llogiq 11y ago
  Yeah, but that's only because teXitoi's and Joshua Landau's improvements to many Rust benchmarks are still open on the tracker. And it's still using 1.3 (Ok, 1.4 only came out yesterday). Note that this is not meant as an indictment of the maintainer, who is indeed working very hard to keep the site usable, accurate and useful.
  - igouy 11y ago
    >>(Ok, 1.4 only came out yesterday).<< Using 1.4 since 3pm PDT yesterday.

vardump 11y ago

I think good support for SIMD will go a long way. C++ is also pretty slow on its own, but with SIMD intrinsics (or lucky autovectorization [1]) it can be speedy. We're talking typically about 1.5 - 10x speedup in performance sensitive code with SIMD vs plain C++. Highest speedup I've seen was about 40x in sorting code. SIMD is a sorting demon. That said, I want safety more than speed. Speed I can get by writing an unsafe extension in C/C++. Safety is very hard to achieve in C/C++. Getting it right is the first priority. That's why I see Rust being used instead of where traditionally C++ is the default. Or some other new language that can fill C++'s shoes. Rust does seem like the strongest candidate at this point. I'm confident Rust and Golang performance will improve as the projects get more mature. The generated code is full of optimization opportunities. [1]: Autovectorization optimizations by C++ compilers tend to be fragile, small changes will undo them. So far easier to use intrinsics than figure out the black magic for autovectorization optimizations.

kibwen 11y ago
Note that SIMD support is currently in the Rust nightlies (as a result of Huon Wilson's summer internship at Mozilla), though I don't know what the timeline is for exposing that support in a stable release.

EugeneOZ 11y ago

Please don't quote this piece of shit. Seller of C++ tool trying to say "use C++ instead of Rust".

yokohummer7 11y ago

Please not this again. The article you mentioned is incorrect in many places, and was heavily criticized in various communities.[1][2] It doesn't qualify as a valid criticism. It is rather a badly written static analyzer promotion. Also, microbenchmarks are usually not very good at representing the real world characteristics. But then again, please look at the current version of the linked benchmark.[3] Rust now positions itself in the second place, thanks to the recent improvements given to the Rust programs used in the benchmarks. I believe Rust isn't as fast as highly optimized C, but I think it is safe to say that Rust is just as fast as C++, and both Rust and C++ are much faster than GC'ed languages such as Java, Haskell, and Go. Edit: I would even say that if Rust's performance is comparable to GC'ed languages, there's no point in using Rust in the first place. Rust is paying a lot of complexity to achieve memory safety without relying on garbage collection. [1] https://news.ycombinator.com/item?id=9531822 https://news.ycombinator.com/item?id=9531822 [2] https://www.reddit.com/r/cpp/comments/35pn6h/criticizing_the_rust_language_and_why_cc_will/cr6o9tz https://www.reddit.com/r/cpp/comments/35pn6h/criticizing_the... [3] http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...

johncolanduoni 11y ago
> Edit: I would even say that if Rust's performance is comparable to GC'ed languages, there's no point in using Rust in the first place. Rust is paying a lot of complexity to achieve memory safety without relying on garbage collection. Rust has a lot of nice safety features not related to memory management that I'd love to see even in a language with GC. On top of the obvious lack of data races, linear types and borrowing are great for ensuring other kinds of sanity like preventing you from mutating a collection while you iterate over it.
- Gankro 11y ago
  Technically Rust doesn't have proper linear typing, only affine typing. Destructors give you "basically" linear typing, but there's ways to bypass destructors both explicitly and accidentally (though if memory safety isn't at stake, this isn't a worth worrying about IMO): https://doc.rust-lang.org/nomicon/leaking.html https://doc.rust-lang.org/nomicon/leaking.html