5 ms·

Rust will be if is not already faster than C. Especially in real-life projects. One example would be https://github.com/BurntSushi/ripgrep https://github.com/Bu

by dpc_pw 10y ago

Rust will be if is not already faster than C. Especially in real-life projects. One example would be https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep Aliasing rules in C make some optimizations not possible in C. Good luck putting that `restrict` everywhere to compensate. Generics with static dispatch makes it possible to get a code that is way better than what a sane person can write with C's preprocessor. Practical developer will very often sacrifice performance for sanity in C codebase. Memory safety makes it easy to write correct, reliable multithreaded programs in Rust and actual package manager makes it practical to reuse well-written and optimized code. Even if there are some microbenchmarks where C gives better results, it's because Rust version doesn't "cheat" by using `unsafe` constructs. Essentially in Rust one can write functionally exactly same code that C uses, including inline asm etc. which is useful for performance-critical libraries that wrap it in safe abstractions, but would be frowned upon in a tiny synthetic benchmark program that is supposed to benchmark idiomatic code.

bjourne 10y ago
It is not already faster and there are benchmarks that proves that. Check out of the The Computer Language Benchmarks Game, for example. Lots of language communities make the claim that "their" language either is or will eventually be faster than C. Haskell, Julia, Go, Java, Swift... But the proof of the pudding is in the eating and so far none of these safer languages has beaten C.
- the_why_of_y 10y ago
  While you can write very fast code in C, that doesn't imply that if you spend the same amount of effort solving the same problem in C and in Rust, the C version will be faster, because Rust's type system lets you write programs that exploit traditionally error-prone things like unique ownership and multi-threading in much less development and debugging time than C.
  - Const-me 10y ago
    Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics. Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.
    - burntsushi 10y ago
      Rust's regex library uses manually vectorized code to speed up its search algorithms, so it follows that Rust's type system is more than OK with such things.
      - Const-me 10y ago
        They were lucky. Those regexps were OK only using a single register representation, u8x16. That’s not always the case. To write efficient SSE code, you need to understand __m128i is a just a hardware register, and use whatever representation you need for particular instruction. Example: http://stackoverflow.com/a/17355341/126995 http://stackoverflow.com/a/17355341/126995 The SSE2 code is impossible to translate to Rust, because _mm_sub_epi8 views the registers as std::simd::i8x16, while the subsequent _mm_srli_epi64 views the same registers as std::simd::i64x2
        burntsushi 10y ago
        It's not impossible at all. You can use the raw intrinsics in Rust just like you'd use them in C if you want to. > The SSE2 code is impossible to translate to Rust, because _mm_sub_epi8 views the registers as std::simd::i8x16, while the subsequent _mm_srli_epi64 views the same registers as std::simd::i64x2 That's false. It might be impossible to implement that code safely using the current simd crate as is (which is not in the standard library), but the simd crate is an abstraction over the raw intrinsics and isn't blessed by the language. You can reach in and use the raw intrinsics (or unsafely cast between SIMD types). If you look more closely at the SIMD algorithm in the regex crate I wrote, you can see that I'm already doing this (to convert from an `&[u8]` to an `u8x16` without bounds checks). Popping up a level, I can understand why this is not obvious from an outside observer. The SIMD story on Rust is very much still evolving, and we don't have it all completely worked out yet. When we do, I predict it will be awesome. :-) I have a whole bunch of ideas on how to use it to improve text search even more!
- steveklabnik 10y ago
  There's been a lot of variance on the benchmark game lately since things are so close; a couple of months ago, Rust was #2 overall, beating out C++ and just a tad slower than C. The areas where Rust lost the most were because explicit SIMD isn't stable yet. We also upgrade LLVM regularly, and that can cause some fluctuations from time to time. (Rust is currently beating C on one benchmark, within a few tenths of a second on a few more, and then way slower on the SIMD-reliant ones)
  - burntsushi 10y ago
    Enabling SIMD on regex-dna is going to help a lot there too. :-) (I hope.)
  - bjourne 10y ago
    But the OP asked "What is the state of C++ vs. Rust?" and I answered "C is still significantly faster than Rust which follows that C++ is too" That is still true because we are discussing the current state of the languages and what you wrote does not affect that. Btw, the last time this topic was discussed we measured the performance using a microbenchmark. Here is the C version: https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9e5b7 https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9... None of the Rust aficionados were able to produce a Rust program (using the nightly build of Rust even) that came close.
    - steveklabnik 10y ago
      Yes, but you then also went on to say that no language will ever do it. Rust _has_ consistently beaten C on many of these benchmarks in the past, and continues to remain very close in the ones that it's not. I actually don't think microbenchmarks are a good way to think about performance anyway. There's two reasons: First, Rust's safety guarantees let you get away with more dangerous things. Consider scoped threads, or non-atomic reference counting.[1] You _could_ write this in C, and you'd do so for a microbenchmark, but not for a real codebase, as it's far too dangerous. Or, you might do it, but end up with bugs that you don't detect, that aren't there in the Rust version. 1: http://blog.faraday.io/saved-by-the-compiler-parallelizing-a-loop-with-rust-and-rayon/ http://blog.faraday.io/saved-by-the-compiler-parallelizing-a... Secondly, microbenchmarks are often "can the best person at language X write something faster than the best person at language Y"? I don't think that's nearly as interesting as "When an average programmer of languages X and Y write a program, which is faster?" Rust's default patterns and style is already extremely fast. It's not a guarantee, mind you, but for real-world usage, it's the average case that matters more.

by dpc_pw 10y ago

bjourne 10y ago

It is not already faster and there are benchmarks that proves that. Check out of the The Computer Language Benchmarks Game, for example. Lots of language communities make the claim that "their" language either is or will eventually be faster than C. Haskell, Julia, Go, Java, Swift... But the proof of the pudding is in the eating and so far none of these safer languages has beaten C.

the_why_of_y 10y ago
While you can write very fast code in C, that doesn't imply that if you spend the same amount of effort solving the same problem in C and in Rust, the C version will be faster, because Rust's type system lets you write programs that exploit traditionally error-prone things like unique ownership and multi-threading in much less development and debugging time than C.
- Const-me 10y ago
  Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics. Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.
  - burntsushi 10y ago
    Rust's regex library uses manually vectorized code to speed up its search algorithms, so it follows that Rust's type system is more than OK with such things.
    - Const-me 10y ago
      They were lucky. Those regexps were OK only using a single register representation, u8x16. That’s not always the case. To write efficient SSE code, you need to understand __m128i is a just a hardware register, and use whatever representation you need for particular instruction. Example: http://stackoverflow.com/a/17355341/126995 http://stackoverflow.com/a/17355341/126995 The SSE2 code is impossible to translate to Rust, because _mm_sub_epi8 views the registers as std::simd::i8x16, while the subsequent _mm_srli_epi64 views the same registers as std::simd::i64x2
      - burntsushi 10y ago
        It's not impossible at all. You can use the raw intrinsics in Rust just like you'd use them in C if you want to. > The SSE2 code is impossible to translate to Rust, because _mm_sub_epi8 views the registers as std::simd::i8x16, while the subsequent _mm_srli_epi64 views the same registers as std::simd::i64x2 That's false. It might be impossible to implement that code safely using the current simd crate as is (which is not in the standard library), but the simd crate is an abstraction over the raw intrinsics and isn't blessed by the language. You can reach in and use the raw intrinsics (or unsafely cast between SIMD types). If you look more closely at the SIMD algorithm in the regex crate I wrote, you can see that I'm already doing this (to convert from an `&[u8]` to an `u8x16` without bounds checks). Popping up a level, I can understand why this is not obvious from an outside observer. The SIMD story on Rust is very much still evolving, and we don't have it all completely worked out yet. When we do, I predict it will be awesome. :-) I have a whole bunch of ideas on how to use it to improve text search even more!
steveklabnik 10y ago
There's been a lot of variance on the benchmark game lately since things are so close; a couple of months ago, Rust was #2 overall, beating out C++ and just a tad slower than C. The areas where Rust lost the most were because explicit SIMD isn't stable yet. We also upgrade LLVM regularly, and that can cause some fluctuations from time to time. (Rust is currently beating C on one benchmark, within a few tenths of a second on a few more, and then way slower on the SIMD-reliant ones)
- burntsushi 10y ago
  Enabling SIMD on regex-dna is going to help a lot there too. :-) (I hope.)
- bjourne 10y ago
  But the OP asked "What is the state of C++ vs. Rust?" and I answered "C is still significantly faster than Rust which follows that C++ is too" That is still true because we are discussing the current state of the languages and what you wrote does not affect that. Btw, the last time this topic was discussed we measured the performance using a microbenchmark. Here is the C version: https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9e5b7 https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9... None of the Rust aficionados were able to produce a Rust program (using the nightly build of Rust even) that came close.
  - steveklabnik 10y ago
    Yes, but you then also went on to say that no language will ever do it. Rust _has_ consistently beaten C on many of these benchmarks in the past, and continues to remain very close in the ones that it's not. I actually don't think microbenchmarks are a good way to think about performance anyway. There's two reasons: First, Rust's safety guarantees let you get away with more dangerous things. Consider scoped threads, or non-atomic reference counting.[1] You _could_ write this in C, and you'd do so for a microbenchmark, but not for a real codebase, as it's far too dangerous. Or, you might do it, but end up with bugs that you don't detect, that aren't there in the Rust version. 1: http://blog.faraday.io/saved-by-the-compiler-parallelizing-a-loop-with-rust-and-rayon/ http://blog.faraday.io/saved-by-the-compiler-parallelizing-a... Secondly, microbenchmarks are often "can the best person at language X write something faster than the best person at language Y"? I don't think that's nearly as interesting as "When an average programmer of languages X and Y write a program, which is faster?" Rust's default patterns and style is already extremely fast. It's not a guarantee, mind you, but for real-world usage, it's the average case that matters more.