NVMe driver in rust with similar perf to C impl (Linux Plumbers 2022) | Hacker News Reader

NVMe driver in rust with similar perf to C impl (Linux Plumbers 2022)

twitter.com

14 pointsmfrw12 comments

Here's a direct link to the talk: https://www.youtube.com/watch?v=Xw9pKeJ-4Bw&t=8040s

Just watched and enjoyed it. The Q&A section had a lot of positive and encouraging feedback. This made me optimistic about Rust kernel support being merged soon, and seeing more of this in the near future.

During the review process of the Rust for Linux patchset, a common comment was "show us what a real-world non-trivial driver looks like in rust". Doing so was always part of the plan, but obvious took some time.

I don't know the exact goal/purpose of this new driver (does it aim to be used in production eventually?) But I suspect that a review on this driver code will help in validating or refuting or improving the work being done by the Rust for Linux crew

I still don’t understand why rust community are so obsessed to compare its performance with C. The strength of C is mostly not about performance but the way it shapes how you think ( and hence it’s weaknesses). Performance is the natural outcome of correct ly applying that school of thought process. So even if rust is faster than C in a specific case it doesn’t necessarily mean everything can be or should be written in Rust.

In my humble opinion, Rust should not be faster than C; C is the closest we can get to the bare-metal without writing assembly.

In my opinion, in the discussion after this talk folks did mention some pointers of why this was achieved. Although, for the same driver, there is a 2.6% drop in perf when used with 3 disks.

Rust could in some very specific cases be faster than C (assuming all other things equal) for the same reason of Fortran: it can disallow aliasing so the compiler could theoretically exploit this to generate faster code

In practice it depends on LLVM

Off to Google -- `What is aliasing?`

Thanks for the pointer :)

When two pointers point to the same place they alias each other (it's alias as in two names for the same thing, but it's a verb as well as a noun)

Rust's &mut borrow is like a pointer guaranteed to be non-null but also guaranteed to never point to memory that can be accessed by another borrow. Or in other words, &mut can't be aliased by other borrows. If you ever try to alias a &mut borrow, the program won't compile.

C's restrict is kind of similar, but it's far less used than &mut. That's because if you violate aliasing restrictions of restrict, it won't generate a compiler error, but will cause UB!

Anyway in Rust, a &mut has exclusive access to a piece of memory, and the compiler may theoretically make use of this fact in optimizations. However, LLVM isn't yet as good as it could be :( first, I think it doesn't implement yet the real good stuff that GCC has (I found this https://internals.rust-lang.org/t/fyi-ibm-is-working-on-llvm... from 2020 but I don't know the state of it), and worse, what it currently has is very buggy, so sometimes the Rust compiler is forced to disable it :(

So, you have this: https://stackoverflow.com/questions/57259126/why-does-the-ru...

Thank you for the elaborate explaination:)

you can write tons of drivers even in python, you'll get roughtly the same speed than C, because the "speed" is elsewhere.

It depends what the driver does. NVMe is a good example because some NVMe drives (especially Optane) are so fast that every cycle of driver overhead is noticeable.

I don't know the details of the hardware interface of NVMe (not ssd, the real NVMe), but how setting up hardware scatter and gater lists for DMA will end up significantly faster, I cannot see any pertinent meaning.

And, is this code compiling with the rust compiler written in rust? (namely not pulling in the SDK this horrible c++ diareha which is gcc).

I have not checked rust syntax lately, but hopefully, it did not become insane like the c++ one (and what they are trying hard to do with C). Even at the start, I really did not like the hardcoding of strings directly into the syntax, but at least it had the decency to not require a garbage collector.

And I am not fond of all those languages. I am more a "everything in risc-v assembly" guy.

Reply on news.ycombinator.com