6 ms·

This was a well-crafted benchmark, but what I found especially interesting and insightful was the "apples to oranges" part: C and Rust encourage distinct approa

This was a well-crafted benchmark, but what I found especially interesting and insightful was the "apples to oranges" part: C and Rust encourage distinct approaches, different data structures. I feel it is actually more interesting than implementing the same algorithm and comparing optimizer pipelines.

cryptonector 8y ago
I agree. Many of us like it about C that we can build intrusive data structures easily enough. The price is more complex memory management and locking protocols, but in some cases the price is too steep in actual run-time cost. The apples to oranges comparison is not telling about whether Rust produces better code than C, but it shows how Rust's design choices force themselves on the coder and yield better results in the end. When you stay away from unsafe code, Rust makes one write code that is much easier to reason about, especially in a threaded environment. Performance is nice, but the nicer thing is correctness -- being able to get good performance along with correctness, now that is really nice.
- TheDong 8y ago
  I think this is more a result of rust having good generics. If c were built with good generics and memory management (not that garbage preprocessor stuff), I expect similarly expressive and good data-structures would be built. C++ is an affirmation of this because it happens to have good libraries of data-structures which are not really very different from rust's. I don't think this is as much "rust's design forces the coder to do this" and more "c makes it hard to do as nice of a design"
  - vnorilo 8y ago
    Right. In C, correctness is by convention, not enforced. C++ allows "userland" enforcement via RAII. There are, however, pieces of compiler magic partially outside the type system (const, &, &&) - you can't specify such behavior within C++. Rust does more of this magic in ownership. If you just want a particular instruction soup, all of them will get you there. It's a question of ergonomics, convenience and the kinds of compiler guarantees that we want.
- cryptonector 8y ago
  C is also expensive in that it's practically impossible to get correctness in large codebases.
  - zbobet2012 8y ago
    The Linux Kernel would beg to differ. I love Rust, I love strong typing, but statements like this are what make people scoff at its evangelist. People can and do get C right, in safety critical systems, at larges scale, all over the world.
    - bboreham 8y ago
      What definition of “correctness” are you using here? Bugs are found and fixed in Linux all the time.
      - jacquesm 8y ago
        Bugs would be found in a Rust codebase all the time as well. The difference is that a certain class of bugs is going to be absent from safe usage of Rust. (Unsafe Rust gives you just as much rope to hang yourself with as C).
        newacctjhro 8y ago
        Unsafe Rust has a little less rope than C because there are less cases that can lead to undefined behavior (see https://doc.rust-lang.org/nomicon/what-unsafe-does.html https://doc.rust-lang.org/nomicon/what-unsafe-does.html and https://doc.rust-lang.org/reference/behavior-considered-undefined.html https://doc.rust-lang.org/reference/behavior-considered-unde...). However, once you trigger UB, it's the same. By the way, Rust devs are working on a mathematical formalization of those rules. Here's a blog post about a part of this effort: https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html. (There are similar formalization efforts for subsets of C, that led to software like the CompCert verified compiler)
    - 8y ago
vmchale 8y ago
Agreed. Comparing compiler pipelines is a poor way to judge how your code will perform in practice, and it's even not that useful for compiler authors, where optimizations that matter in practice are not the same.
quotemstr 8y ago
Rust and C may encourage different data structures, but a benchmark of two programs that happen to use two different data structures doesn't demonstrate this difference. To demonstrate what you claim, you'd have to perform a more holistic language analysis than we see in the article, and you'd in practice have to talk about C++ too.
- kiriakasis 8y ago
  That Rust and C use different data structure is not a thesis in the article, it is used as a fact in an explanation. To support this fact the author explain how intrusive data structure are easier in C thanks to a lack of static ownership (for the same reason they are way harder in Rust). To demonstrate the claim that C and Rust have different idiomatic data structures you need to rewrite software from C to Rust and to Rust from C and see what is hard and what is less hard.
stochastic_monk 8y ago
How is Rust encouraging a different data structure besides providing a btree set and not an avl tree set? The C stdlib does not come with an AVL tree. Why would one not implement a b-tree in C for this comparison? It’s not as if K&R has “Use binary, not b-trees!” on the front cover.
- ummonk 8y ago
  Yes, especially when b trees tend to be easier to implement too.
- marcosdumay 8y ago
  Rust encourages the creation of more generic code, that makes switching into non-DIY more complex data structures easier. The difference is even larger after the code is written and you are able to profile it.
  - stochastic_monk 8y ago
    Then Heng Li’s kbtree.h from klib is your generic, fast implementation. I’d love to see this repeated using it for a fair comparison. For example, the benchmark shootout recommends his khash for a hash table.
    - marcosdumay 8y ago
      The point is entirely that it is harder to take a typical C code and change it to use something like this than it is to do the same in Rust. Much harder. I don't think anybody will find any consistent performance enhancement in Rust that can not be replicated in C. The problem is how to run it out on real code.
      - stochastic_monk 8y ago
        That’s fair. klib (I assume) was not easy to develop, but it easy to use.

cryptonector 8y ago

I agree. Many of us like it about C that we can build intrusive data structures easily enough. The price is more complex memory management and locking protocols, but in some cases the price is too steep in actual run-time cost. The apples to oranges comparison is not telling about whether Rust produces better code than C, but it shows how Rust's design choices force themselves on the coder and yield better results in the end. When you stay away from unsafe code, Rust makes one write code that is much easier to reason about, especially in a threaded environment. Performance is nice, but the nicer thing is correctness -- being able to get good performance along with correctness, now that is really nice.

TheDong 8y ago
I think this is more a result of rust having good generics. If c were built with good generics and memory management (not that garbage preprocessor stuff), I expect similarly expressive and good data-structures would be built. C++ is an affirmation of this because it happens to have good libraries of data-structures which are not really very different from rust's. I don't think this is as much "rust's design forces the coder to do this" and more "c makes it hard to do as nice of a design"
- vnorilo 8y ago
  Right. In C, correctness is by convention, not enforced. C++ allows "userland" enforcement via RAII. There are, however, pieces of compiler magic partially outside the type system (const, &, &&) - you can't specify such behavior within C++. Rust does more of this magic in ownership. If you just want a particular instruction soup, all of them will get you there. It's a question of ergonomics, convenience and the kinds of compiler guarantees that we want.
cryptonector 8y ago
C is also expensive in that it's practically impossible to get correctness in large codebases.
- zbobet2012 8y ago
  The Linux Kernel would beg to differ. I love Rust, I love strong typing, but statements like this are what make people scoff at its evangelist. People can and do get C right, in safety critical systems, at larges scale, all over the world.
  - bboreham 8y ago
    What definition of “correctness” are you using here? Bugs are found and fixed in Linux all the time.
    - jacquesm 8y ago
      Bugs would be found in a Rust codebase all the time as well. The difference is that a certain class of bugs is going to be absent from safe usage of Rust. (Unsafe Rust gives you just as much rope to hang yourself with as C).
      - newacctjhro 8y ago
        Unsafe Rust has a little less rope than C because there are less cases that can lead to undefined behavior (see https://doc.rust-lang.org/nomicon/what-unsafe-does.html https://doc.rust-lang.org/nomicon/what-unsafe-does.html and https://doc.rust-lang.org/reference/behavior-considered-undefined.html https://doc.rust-lang.org/reference/behavior-considered-unde...). However, once you trigger UB, it's the same. By the way, Rust devs are working on a mathematical formalization of those rules. Here's a blog post about a part of this effort: https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html. (There are similar formalization efforts for subsets of C, that led to software like the CompCert verified compiler)
  - 8y ago

vmchale 8y ago

Agreed. Comparing compiler pipelines is a poor way to judge how your code will perform in practice, and it's even not that useful for compiler authors, where optimizations that matter in practice are not the same.

quotemstr 8y ago

Rust and C may encourage different data structures, but a benchmark of two programs that happen to use two different data structures doesn't demonstrate this difference. To demonstrate what you claim, you'd have to perform a more holistic language analysis than we see in the article, and you'd in practice have to talk about C++ too.

kiriakasis 8y ago
That Rust and C use different data structure is not a thesis in the article, it is used as a fact in an explanation. To support this fact the author explain how intrusive data structure are easier in C thanks to a lack of static ownership (for the same reason they are way harder in Rust). To demonstrate the claim that C and Rust have different idiomatic data structures you need to rewrite software from C to Rust and to Rust from C and see what is hard and what is less hard.

stochastic_monk 8y ago

How is Rust encouraging a different data structure besides providing a btree set and not an avl tree set? The C stdlib does not come with an AVL tree. Why would one not implement a b-tree in C for this comparison? It’s not as if K&R has “Use binary, not b-trees!” on the front cover.

ummonk 8y ago
Yes, especially when b trees tend to be easier to implement too.
marcosdumay 8y ago
Rust encourages the creation of more generic code, that makes switching into non-DIY more complex data structures easier. The difference is even larger after the code is written and you are able to profile it.
- stochastic_monk 8y ago
  Then Heng Li’s kbtree.h from klib is your generic, fast implementation. I’d love to see this repeated using it for a fair comparison. For example, the benchmark shootout recommends his khash for a hash table.
  - marcosdumay 8y ago
    The point is entirely that it is harder to take a typical C code and change it to use something like this than it is to do the same in Rust. Much harder. I don't think anybody will find any consistent performance enhancement in Rust that can not be replicated in C. The problem is how to run it out on real code.
    - stochastic_monk 8y ago
      That’s fair. klib (I assume) was not easy to develop, but it easy to use.