4 ms·

i'd be curious if they're using the same llvm codegen (with the same optimization) backend for the c and rust versions. if so, where the speedups are coming fro

by a-dub 1y ago

i'd be curious if they're using the same llvm codegen (with the same optimization) backend for the c and rust versions. if so, where the speedups are coming from? (ie, is it some kind of rust auto-simd thing, did they use the opportunity to hand optimize other parts or is it making use of newer optimized libraries, or... other)

eru 1y ago
Just speculating: Rust can hand over more hints to the code generator. Eg you don't have to worry about aliasing as much as with C pointers. See https://en.wikipedia.org/wiki/Aliasing_(computing)#Conflicts_with_optimization https://en.wikipedia.org/wiki/Aliasing_(computing)#Conflicts...
- MBCook 1y ago
  This makes a lot of sense to me, though I don’t know the official answer so I’m just sort of guessing along too. Linked from the article is another on how they used c2rust to do the initial translation. https://trifectatech.org/blog/translating-bzip2-with-c2rust/ https://trifectatech.org/blog/translating-bzip2-with-c2rust/ For our purposes, it points out places where the code isn’t very optimal because the C code has no guarantees on the ranges of variables, etc. It also points out a lot of people just use ‘int’ even when the number will never be very big. But with the proper type the Rust compiler can decide to do something else if it will perform better. So I suspect your idea that it allows unlocking better optimizations though more knowledge is probably the right answer.
- Too 1y ago
  Ergonomics of using the right data structures and algorithms can also play a big role. In C, everything beyond a basic array is too much hassle.
  - littlestymaar 1y ago
    Yeah, that was Brian Cantrill's realization when for the sake of learning he rewrote a part of dtrace in Rust and was shocked when he saw his naive reimplementation being significantly faster than his original code, and the answer boiled down to “I used a BTreeMap" in Rust because it's in std”.
    - a-dub 1y ago
      hmm.. i wonder how it would compare then with clang+linux, clang+stl or hotspot+j2ee. reminds me a bit of the days when perl programs would often outrun native c/c++ for common tasks because ultimately they had the most efficient string processing libraries baked into the language built-ins. how is space efficiency? last i checked, because of big libraries and ease of adding them to projects, a lot of rust binaries tend to be much larger than their traditional counterparts. how might this impact overall system performance if this trade-off is made en-masse? (even if more ram is added to counteract loss of vm page cache, does it also start to impact locality and cache utilitization?) i'd be curious how something like redox benchmarks against traditional linux for real world workloads and interactivity measures.
      - bcantrill 1y ago
        For whatever it's worth, details of my findings are in [0]. [0] https://bcantrill.dtrace.org/2018/09/28/the-relative-performance-of-c-and-rust/ https://bcantrill.dtrace.org/2018/09/28/the-relative-perform...
        a-dub 1y ago
        pretty cool! in isolation looks awesome! i'm still a little curious about the impacts increased executable image size, especially in a complete system. if all the binaries are big, does it start to crowd out cache space? does static linking make sense for full systems?
        eru 1y ago
        The kernel will only load the parts of the binary you actually run, and can drop the disk cache for those parts that haven't been ran in a while. So more than the absolute size of the binary, you should worry about how much is actually in the 'active set'.
    - eru 1y ago
      And even non standard library crates are really easy to use in Rust.
WhereIsTheTruth 1y ago
any rewrite, in X, Y, Z language gives you the opportunity to speed things up, there is nothing inherent to rust
adgjlsfhk1 1y ago
C is honestly a pretty bad language for writing modern high performance code. Between C99 and C21, there was a ~20 year gap where the language just didn't add features needed to idiomatically target lots of the new instructions added (without inline asm). Just getting good abstract machine instructions for clz/popcnt/clmul/pdep etc helps a lot for writing this kind of code.
- zzo38computer 1y ago
  Popcount, clz, and ctz are provided as nonstandard functions in GCC (and clang might also support them in GNU mode, but I don't know for sure). PDEP and PEXT do not seem to be, but I think they should be (and PEXT is something that INTERCAL already had, anyways) (although PDEP and PEXP can be used with -mbmi2 on x86, but are not available for general use). The MOR and MXOR of MMIX are also something that I would want to be available as built-in functions.

by a-dub 1y ago

eru 1y ago

Just speculating: Rust can hand over more hints to the code generator. Eg you don't have to worry about aliasing as much as with C pointers. See https://en.wikipedia.org/wiki/Aliasing_(computing)#Conflicts_with_optimization https://en.wikipedia.org/wiki/Aliasing_(computing)#Conflicts...

MBCook 1y ago
This makes a lot of sense to me, though I don’t know the official answer so I’m just sort of guessing along too. Linked from the article is another on how they used c2rust to do the initial translation. https://trifectatech.org/blog/translating-bzip2-with-c2rust/ https://trifectatech.org/blog/translating-bzip2-with-c2rust/ For our purposes, it points out places where the code isn’t very optimal because the C code has no guarantees on the ranges of variables, etc. It also points out a lot of people just use ‘int’ even when the number will never be very big. But with the proper type the Rust compiler can decide to do something else if it will perform better. So I suspect your idea that it allows unlocking better optimizations though more knowledge is probably the right answer.
Too 1y ago
Ergonomics of using the right data structures and algorithms can also play a big role. In C, everything beyond a basic array is too much hassle.
- littlestymaar 1y ago
  Yeah, that was Brian Cantrill's realization when for the sake of learning he rewrote a part of dtrace in Rust and was shocked when he saw his naive reimplementation being significantly faster than his original code, and the answer boiled down to “I used a BTreeMap" in Rust because it's in std”.
  - a-dub 1y ago
    hmm.. i wonder how it would compare then with clang+linux, clang+stl or hotspot+j2ee. reminds me a bit of the days when perl programs would often outrun native c/c++ for common tasks because ultimately they had the most efficient string processing libraries baked into the language built-ins. how is space efficiency? last i checked, because of big libraries and ease of adding them to projects, a lot of rust binaries tend to be much larger than their traditional counterparts. how might this impact overall system performance if this trade-off is made en-masse? (even if more ram is added to counteract loss of vm page cache, does it also start to impact locality and cache utilitization?) i'd be curious how something like redox benchmarks against traditional linux for real world workloads and interactivity measures.
    - bcantrill 1y ago
      For whatever it's worth, details of my findings are in [0]. [0] https://bcantrill.dtrace.org/2018/09/28/the-relative-performance-of-c-and-rust/ https://bcantrill.dtrace.org/2018/09/28/the-relative-perform...
      - a-dub 1y ago
        pretty cool! in isolation looks awesome! i'm still a little curious about the impacts increased executable image size, especially in a complete system. if all the binaries are big, does it start to crowd out cache space? does static linking make sense for full systems?
        eru 1y ago
        The kernel will only load the parts of the binary you actually run, and can drop the disk cache for those parts that haven't been ran in a while. So more than the absolute size of the binary, you should worry about how much is actually in the 'active set'.
  - eru 1y ago
    And even non standard library crates are really easy to use in Rust.

WhereIsTheTruth 1y ago

any rewrite, in X, Y, Z language gives you the opportunity to speed things up, there is nothing inherent to rust

adgjlsfhk1 1y ago

C is honestly a pretty bad language for writing modern high performance code. Between C99 and C21, there was a ~20 year gap where the language just didn't add features needed to idiomatically target lots of the new instructions added (without inline asm). Just getting good abstract machine instructions for clz/popcnt/clmul/pdep etc helps a lot for writing this kind of code.

zzo38computer 1y ago
Popcount, clz, and ctz are provided as nonstandard functions in GCC (and clang might also support them in GNU mode, but I don't know for sure). PDEP and PEXT do not seem to be, but I think they should be (and PEXT is something that INTERCAL already had, anyways) (although PDEP and PEXP can be used with -mbmi2 on x86, but are not available for general use). The MOR and MXOR of MMIX are also something that I would want to be available as built-in functions.