9 ms·

I thought the tl;dr was: Implementing B-trees as an embeddable library in C is hard, therefore Rust is faster.

• kenhwang 8y ago
  Rust makes hard problems easier, but easy problems harder. BTrees are a great example of that sentiment.
  • TheDong 8y ago
    Let's look at some problems in C which should be easy: 1. Storing an array and its length together and always checking it correctly such that you don't have a buffer overrun. 2. Freeing memory, not leaking memory. 3. Using a union correctly, e.g. always accessing the right variant. 4. Printing unicode characters. 5. Macros which dont' conflict with their scope (are hygenic) All of those problems seem like they should be easy, are incredibly easy in rust, and are not fully solved problems in C. I don't think rust makes easy problems harder just because its type-system and macro system and such are all so good compared to C. It turns out having proper sum types instead of C's garbage unions, and having proper string support, and so on make easy problems easy too!
    • paulddraper 8y ago
      The problem that Rust makes hard: linked lists.
      • Animats 8y ago
        Doubly linked lists. Singly linked lists and one-way trees work fine with the single ownership model. As I've said before, the two places where Rust has problems with expressive power are backlinks and partially initialized arrays. Those are routine cases which are forced to unsafe code.
        • Rusky 8y ago
          Please, these are not interesting or useful talking points. You always get the same responses: Partially initialized arrays are a solved problem- anything more would just be baking `Vec` into the language. And backlinks are nowhere near "routine."
          • nixpulvis 8y ago
            Backlinks ARE a very interesting point about Rust. Just because you don't find yourself using them all that often doesn't mean it's not interesting to the design and expresivity of the language. The issue is a direct consequence of Rust's strict aliasing rules, which I feel any programmer would benefit from groking.
          • acjohnson55 8y ago
            They're routine in CS classes. Curiously, I've never needed to use them in real life.
            • btmorex 8y ago
              Except really common things like LRU caches use them.
              • chousuke 8y ago
                I think it's important to note that in the case of most data structures, you only need to do the hard work of verifying your unsafe code once, after which you can package it up in a crate. I guess many C programmers might be used to reimplementing data structures for their programs, but I don't think it's useful in a majority of cases
                • yjftsjthsd-h 8y ago
                  Why would libraries be more common in Rust than C?
      • v_lisivka 8y ago
        No, it's not harder than in C++. Compare: https://gist.github.com/stjepang/07fbf88afa824e11796e51ea2f68bd5a https://gist.github.com/stjepang/07fbf88afa824e11796e51ea2f6... , https://gist.github.com/stjepang/fc20ea97030a2153148117dddeb239b3 https://gist.github.com/stjepang/fc20ea97030a2153148117dddeb... . In Rust, it even works faster (with array bounds check!).
        • TheDong 8y ago
          Please just use an `Option<usize>`, not that wonky NULL thing. If you're worried about the slightly more memory that uses, you can use `Option<NonZeroUsize>` and subtract 1 for all indexing operations.
• namibj 8y ago
  klib's kbtree header/macro library seems to provide rather nice B-trees in C. https://github.com/attractivechaos/klib/blob/master/kbtree.h https://github.com/attractivechaos/klib/blob/master/kbtree.h
• kibwen 8y ago
  I think that TL;DR misses lots of nuance; I'd suggest a better TL;DR would be "the features and idioms of different languages can lead to different preferred solutions to the same problems, which means that we should be careful not to unnecessarily restrict our perception of new languages in terms of the familiar idioms of old ones." Or maybe: "performance benchmarks are hard, and even carefully-crafted comparisons can miss the point if they paper over important practical implementation concerns; an apples-to-apples comparison can unintentionally mislead if it precludes the consideration that perhaps what you actually wanted was an orange after all". Importantly, the article explains why Rust is faster on this specific benchmark, but goes out of its way to note that benchmarks should always be interpreted with appropriate caution, and that nobody should come away with the notion that this implies any sort of strict dominance of Rust over C.
  • igouy 8y ago
    So it's called "The relative performance of C and Rust" to put the emphasis on the data structures? :)
    • kibwen 8y ago
      As suggested in the introduction, one would think it was called "the relative performance of C and Rust" because this article is a corollary to a previous article and conceived as a response to an inquiry regarding that previous article--specifically, to answer the question "in your given benchmark, what explains the relative performance of C and Rust?" :P The basic answer: "data structures"; the insightful answer: "data structures that were originally chosen to play to the different strengths and weaknesses of their respective implementation languages, giving us food for thought as to how language design can shape the solutions that users of that language will tend to arrive at, and the performance implications thereof".
      • igouy 8y ago
        Obviously Why Rust BTreeMaps beat C AVL Trees is way too-long and misleading a title ;-)
• igouy 8y ago
  Might there be a C library that could be used? https://old.reddit.com/r/programming/comments/9jsqb3/the_relative_performance_of_c_and_rust/e6umut4/?st=jmo70uic&sh=d3f0d1cf https://old.reddit.com/r/programming/comments/9jsqb3/the_rel...