Announcement

Collapse
No announcement yet.

Rust Infrastructure Pull Request Submitted For Linux 6.1!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Mitch View Post

    I remember these tests. Someone correct me if I'm wrong,.
    Yup, this is correct.
    The are some cases where doing on par performance with C is hard, because the C code is doing something inherently unsafe with is hard to represent in a safe way in rust. But then you can always switch to unsafe in that critical part and do it mostly like C does.

    Comment


    • #12
      Originally posted by Azrael5 View Post
      What's the benefit to integrate Rust in the kernel?
      being able to get rid of C

      Comment


      • #13
        Originally posted by Mitch View Post
        .... but her overall impression while working on some M1 GPU stuff was very positive for Rust and her only criticism is that it could do with one or two additional features to close a parity gap (presumably with C).
        There are known to be bindings/functionality that are not yet available, but they can be added in future patches as the needs are better understood by those that will be writing drivers in rust (in some cases it may be better to refactor rather than just adding simple wrappers). The early (rust driver) adopters will almost certainly have some interesting things to share.

        Comment


        • #14
          Originally posted by Azrael5 View Post
          What's the benefit to integrate Rust in the kernel?
          It is probably worthwhile to look at the original proposal goals:

          Goals

          By using Rust in the Linux kernel, our hope is that:

          - New code written in Rust has a reduced risk of memory safety bugs, data races and logic bugs overall, thanks to the language properties mentioned below.

          - Maintainers are more confident in refactoring and accepting patches for modules thanks to the safe subset of Rust.

          - New drivers and modules become easier to write, thanks to abstractions that are easier to reason about, based on modern language features, as well as backed by detailed documentation.

          - More people get involved overall in developing the kernel thanks to the usage of a modern language.

          - By taking advantage of Rust tooling, we keep enforcing the documentation guidelines we have established so far in the project. For instance, we require having all public APIs, safety preconditions, `unsafe` blocks and type invariants documented.​

          Comment


          • #15
            The beginning of a shiny new future.

            Comment


            • #16
              Originally posted by Jakobson View Post
              Rustaceans like very much. But please give me some performance figures. If you don't have ay then I do not celebrate either.
              Ah, the old fallacy.
              It's not performance you should be worried about. It's been proven time and again Rust is every bit as fast as C. The thing about Rust is that it lets you write code that's as fast as C, but you can write that code much faster (because memory safety is the compiler's job, not yours). As an added bonus, when the compiler slaps your wrist when you try to do stupid things, even the design in Rust can be better.

              Comment


              • #17
                Originally posted by bug77 View Post

                Ah, the old fallacy.
                It's not performance you should be worried about. It's been proven time and again Rust is every bit as fast as C. The thing about Rust is that it lets you write code that's as fast as C, but you can write that code much faster (because memory safety is the compiler's job, not yours). As an added bonus, when the compiler slaps your wrist when you try to do stupid things, even the design in Rust can be better.
                In fact in some instances Rust has led to better performance than C for four reasons:

                - Rust makes it easier to implement better algorithms
                - Rust can perform low level optimisations that are impossible in C
                - Rust is generally better at autovectoring than C
                - Rust makes it much easier to parallelise the code

                Those advantages may or may not apply to the kernel in varying degrees but it's important to keep in mind that C is not inherently an exceptionally efficient language. The supposedly unbeatable performance of C is largely a myth.

                Comment


                • #18
                  Originally posted by jacob View Post

                  In fact in some instances Rust has led to better performance than C for four reasons:

                  - Rust makes it easier to implement better algorithms
                  - Rust can perform low level optimisations that are impossible in C
                  - Rust is generally better at autovectoring than C
                  - Rust makes it much easier to parallelise the code

                  Those advantages may or may not apply to the kernel in varying degrees but it's important to keep in mind that C is not inherently an exceptionally efficient language. The supposedly unbeatable performance of C is largely a myth.
                  Indeed, C is considered "fast" because it's merely been the fastest available.

                  Comment


                  • #19
                    Originally posted by Developer12 View Post

                    Indeed, C is considered "fast" because it's merely been the fastest available.
                    Not even that. Fortran has always been faster. Plus C's million dollar mistake with zero terminated strings means that trivial operations like strlen() are O(n) instead of O(1). C is considered fast because its bias towards base+offset addressing was well suited for the PDP11. Later, CPUs' branch predictors and other heuristics were based on stats derived from existing code, that is mostly C. So essentially CPU manufacturers made huge efforts to produce CPUs where C could run well, rather than the other way around.
                    Last edited by jacob; 01 October 2022, 10:47 PM.

                    Comment


                    • #20
                      Originally posted by Mitch View Post

                      I remember these tests. Someone correct me if I'm wrong, but I think it has been said and shown, ad nausium, that rust pays a higher overhead only during compile, not runtime. And whenever there's a runtime difference, it's within a margin of error. The compile-time overhead seems to help developers save time and focus their attention far less on memory and thread management so they can be more ambitious on things like performance and parallelism. I think Asahi Lina was talking about the pros and cons of Rust, but her overall impression while working on some M1 GPU stuff was very positive for Rust and her only criticism is that it could do with one or two additional features to close a parity gap (presumably with C).

                      I'm not a dev for this kind of programming, and I have no skin in this game. Just trying to recall what I remember.
                      Rust's compile time overhead isn't even bad, I find it well within expectations. The complaints seem to be from people coming in from Python... which well yeah it's not going to be instantaneous like an interpreted scripting language.... but if you're coming from another normal compiled language it's.... average. No better or worse than anything else in the category.

                      Comment

                      Working...
                      X