Announcement

Collapse
No announcement yet.

LPC 2022: Rust Linux Drivers Capable Of Achieving Performance Comparable To C Code

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

  • #11
    Originally posted by PAUL007 View Post
    Is modern Cpp bad for memory handling ?
    Yes. It's less tragic than old cpp but still extremely bad. But most importantly cpp is a very bad language for use with a kernel. And Linus refuses to allow cpp in Linux but he's not opposed to Rust.

    Comment


    • #12
      Originally posted by cardich View Post
      Hooray! Rust has got it made in reinventing the wheel.
      Yes, just a nicer one that - albeit being non production code - rolls as fast as the battle tested C one.

      You understand the term "proof of concept", don't you?

      Comment


      • #13
        Originally posted by cardich View Post
        Hooray! Rust has got it made in reinventing the wheel.
        yup, linux is finally begin to accept rubber wheels alongside the wooden ones

        Comment


        • #14
          IMO the main reason why NVMe is an interesting test case is that it is representative of any driver for modern high-speed hardware, with multiple I/O queues to be managed.

          For people asking why C++ is not used, my personal take on C++ is that it has more abstraction capability just like Rust, but the abstractions you build with C++ are leaky, in other words you still need to understand many details of the abstraction to use it correctly. Rust on the other hand is a little less expressive but focuses on allowing you to build watertight abstractions that you can absolutely rely on. That makes the pain/gain ratio much more favorable, at least in my opinion.

          Of course in the end, the reason why C++ is not used is that Linus does not like C++, and he has his own reasons. He is undecided but open minded about Rust.
          Last edited by zcansi; 13 September 2022, 03:31 AM.

          Comment


          • #15
            Originally posted by Developer12 View Post
            I'm not sure why anyone would be surprised by this. The rust driver does essentially the same job, while rust itself accomplishes all it's checks at compile-time. There's no runtime overhead. As bugs in various systems of tagging get worked out in LLVM, it's quite possible that rust will pull ahead of C/C++ thanks to optimizations that currently can't be deployed upon C/C++ code.
            Exactly. The discussion should not be centered around performance, it should be about time-to-market. How long does it take to write (and fix) C vs Rust code. That is where C leaves you hanging while Rust's compiler bends over backwards for you.

            Comment


            • #16
              Originally posted by cardich View Post
              Hooray! Rust has got it made in reinventing the wheel.
              I expected to see at least one fist shaker under this article and you didn't disappoint me, thanks.

              Comment


              • #17
                Originally posted by PAUL007 View Post
                Is modern Cpp bad for memory handling ?
                It really depends. You can easily shoot yourself into the foot but you can use smart pointers and a crash handler who sends dumps. Most of our crashes happen in the graphics driver. But this are not the serious bugs.

                Most serious bugs have their root into code which was hacked under time pressure. They are not crashes but strange behavior. And most crashes are simply running into asserts. I don't see how Rust would fix that. I think more test driven development could help but that is hard to enforce. Nobody wants pseudo tests.

                Actually I was surprised that Rust is not stronger on this front. You could do much more on the language level to make testing easier. You can not catch all bugs at compile time. Most input is happening at runtime. So you need tests for that.

                Comment


                • #18
                  Originally posted by patrick1946 View Post

                  It really depends. You can easily shoot yourself into the foot but you can use smart pointers and a crash handler who sends dumps. Most of our crashes happen in the graphics driver. But this are not the serious bugs.

                  Most serious bugs have their root into code which was hacked under time pressure. They are not crashes but strange behavior. And most crashes are simply running into asserts. I don't see how Rust would fix that. I think more test driven development could help but that is hard to enforce. Nobody wants pseudo tests.

                  Actually I was surprised that Rust is not stronger on this front. You could do much more on the language level to make testing easier. You can not catch all bugs at compile time. Most input is happening at runtime. So you need tests for that.
                  Rust is not ADA or SPARK (especially that one). Rust only aimed to have memory safety, better concurrency and avoiding few bad design choices like multi-polimorphism and exceptions. Rust was not made to catch all bugs, it was meant to fix memory related issues that are hard to track and fix.

                  Comment


                  • #19
                    Originally posted by piotrj3 View Post

                    Rust is not ADA or SPARK (especially that one). Rust only aimed to have memory safety, better concurrency and avoiding few bad design choices like multi-polimorphism and exceptions. Rust was not made to catch all bugs, it was meant to fix memory related issues that are hard to track and fix.
                    Arguably neither is Ada nor Spark meant to catch all bugs. They're (Ada, Spark, Rust, etc) just meant to catch more problems and flaws than what came before. There's really nothing going to stop logic flaws in program design, for example, other than better education on programming logic and a good grasp of the problem domain. There are plenty of professional programmers out there that don't know how to create proper logic charts for programs. Better, safer, and more precise tools, better education, make for better end results. C was a very blunt instrument created in a time when we were just figuring out how to tell computers how to do anything at all. C++ was meant to plaster over C's problems and ended up adding more of its own (by putting too much trust in the programmer). Unfortunately what happened with the development process and forced implementation of Ada poisoned the well for a long time to come. C/C++ was "good enough" and it was what hardware makers were targeting with their optimizations. It didn't help that people that should have known better were and still are worshiping at the altar of C with all the excuses and massive efforts to "fix" what's essentially unfixable. Humans are fallible. Humans will always make mistakes. There isn't a single programmer out there that can write flawless C or C++ code 100% of the time day in and day out no matter how experienced they are. That's why we need safer tools to protect ourselves from our own inattention and foolishness. More safely implemented languages are one such tool. The industry needs to move past the egos (and profit/performance at all costs) and focus on the science of what works and what isn't working.

                    Comment


                    • #20
                      If a few years I will read about how hard it is to maintain rust code in the kernel ...

                      Comment

                      Working...
                      X