Did RUST beat C in THIS Linux Driver?

Did RUST beat C in NVME Linux Driver Implementation? We'll go through the benchmarks that were presented during the Linux Plumbers Conference and see how RUST and C compare when it comes to performance in the Linux Kernel Drivers.

My Linux Cheat Sheet and 25 Page Checklist here:

Share this free tool and support Small YouTubers
(I made this tool to help creators)

Want more info/content?

Discord Community:

Useful Links:

#driver #linux #opensource

[yondaime]

It's really nice how Rust lets you have high level syntax like iterators and optional values, and all those sanity checks that prevent you from making stupid mistakes, and it all disappears completely during compilation to yield the same performance as C.

[shahab]

I wouldn't be surprised if they came back next year with parity in all cases. C has been around a very long time and these drivers have had plenty of work and iteration to mature. I'm sure with the same treatment rust will just be a 1:1 parity sooner or later

[tremon]

This shows that rust is actually a very good language for low level programming. We have to take into account that the c compilers have been optimized for a lot of years. Rust compilers are pretty new. We should also have information about the development time used for both drivers

[jonaskoelker]

Hm. I'm not sure what to make of those bar charts. I would assume that performance measured in IO op/s depends primarily on two factors: (a) the capabilities of the hardware; and (b) whether you issue the right commands in the right order at the right time. I would think, perhaps naively, that every language capable of issuing the commands to begin with (e.g. C++ but not javascript) should get rough-ballpark identical performance.

I mean, yeah ok, some compilers might do a better job around function entry/exit or incrementing the loop counter or whatever, but I suspect that to be small fry compared to steering the hardware the best way.

The most interesting thing to be learned about Rust as compared to C from this kind of exercise is to be found in questions like "what proportion of the Rust code uses the unsafe keyword" and "what are the relative line counts". Massively different line counts should suggest that language X is more than Y. Large fractions of unsafe Rust suggests that the unique benefit of Rust (the automatically checked memory safety) had to be given up in order to do this kind of work.

It's nice to get confirmation of what I already believed after having seen similar numbers in the language benchmark game: that Rust and C have approximately equivalent performance at compute-heavy tasks. But diluting the compute with IO waters down the message and I'm not sure I gained much insight into the relative usefulness or suitability of Rust vs. C for this kind of work.

[DarkGT]

Even if there were a performance drawbacks, it's still a good idea considering the added security. Some seasoned C/C++ devs have argued that Rust doesn't matter if the programs was written good in first place, but I think is human to make mistakes and you can't always rely for mistakes free C code.

[coenvalk]

nice data. might be useful to include error bars for the average across multiple test runs. the differences look so small it might not even be statistically significant in some cases

[insertoyouroemail]

With better static analysis you can generally do more aggressive optimizations ahead of time. Rust doesn't need to get better performance than C to be much better than C. If you can create correct software faster with less talented engineers that is very important for the ecosystem.

[scottfranco]

I'd be surprised if they were not similar. The CPU is not in the data path for an NVME drive (nor basically any modern disk controller). Its all DMA. The difference would show more in the size of binaries.

[Arrix]

Going out on a limb and say the Rust compiler is actually a standard C compiler with a Rust translator on top. That's why it performs the same.

[yondaime]

Fun fact: the "Filho" in the author's name is the Portuguese equivalent of "Junior" (although some names in Portuguese use "Junior" as well). It literally means "son". Also, the "ilh" is pronounced like the "illi" in "billion".

[ARitzCracker]

>99% of the performance with 0% of the anxiety that comes with programming in C, I'll take it

[iloveblender]

I do not know how hard it is to learn RUST, but if the perfomrance is C-like and the language prevents coding mistakes, it sounds like a good idea.

[wazzamolloy]

When writing Rust drivers in Linux, they use the GCC Rust front end instead of the more mature Rust compiler, so there is scope for improvements in compiler optimisations there, also.

[PhilfreezeCH]

Nice, looks like Rust is also able to hit what is probably the maximum achievable performance given reasonable constraints (ie not just testing every combination of assembler until you find the fastest one, running on slightly different hardware etc).
I would guess the performance gaps presented are not really due to Rust but more due to the implementation. The C implementation has years of optimization and experience behind it, the Rust one not so much.

[brianevans]

i don't know if the drivers have been written, but I would be very interested to see those graphs with more languages on. Eg C, C++, Go, Rust, Zig. All on the same graph, to see how they stack up against each other in this test.

[hurtfulcomment]

Good job Rust! However, I would be interested to hear how many unsafe-blocks this driver has. What would be the point of using Rust, if you are not leaning on the superior memory safety features of the language, just to be able to compete with C?

[michaelplaczek]

Very interesting to see that the performance of Rust is almost at the performance of C. Maybe in a few years, Rust will be faster than C. But, I think it will eventually only be EVER SO SLIGHTLY faster than C.

[etopowertwon]

Did anyone made code review between rust and C implementation? It's interesting what's more readable.

[jonshouse]

One language similar to another on I/O bound workload .... well, errrr, yes I suspect the real bottom line for all of this is that Rust differs from C in the extra time taken for bounds checking, I suspect if you compare the assembler output of the two that is also what you would see. Any language with bounds tests will be always be slower than C by that overhead even if every other parts of compiler are fully optimized.

[bazoo]

I would say that what is shows is how far compiler technology has advanced. This was a pretty long way to say "C and rust compilers used to build Linux kernel are on par" - what this video misses is a bit of interpretation - which compiler front end, code generator and optimizer was used, was there some "secret sauce" in that area worth discussing...