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

[RahulSundaram]

Jesus Christ, I noticed you know (almost?) everything and be up-to-date with everything, are you a robot or what?

Ha! Would a sentient AI admit to it's existence? But really, all I do here is mostly read up on a topic before commenting. Shocking, I know. I do have a few decades of industry experience which helps a bit.

[bug77]

Many people seem to believe that safe code is somehow detrimental to performance or that a lower level language allows for some performance-improving "hacks". That's not necessarily true at all. A strong type system, together with borrow checking, lifetime analysis etc. can enable the compiler to perform some optimisations that are not readily feasible in C, like implicit destructuring, memory access reordering etc. Back when C was created, the primary goal was not performance but the ease to write and/or port a compiler. There was basically a 1-to-1 match between a C source code and the generated assembly, which in turn had a 1-to-1 match to the operations actually performed by the CPU. But this is a very different world, with complex out-of-order execution, register renaming, non-intuitive memory consistency models, hardware multithreading, SIMD and/or variable length vector instructions that we would like the compiler to take advantage of automatically as appropriate, etc. In this context, a more abstract language is a performance benefit, not a hindrance.

What I hinted at is that, for example, if you know (or you just luckily guess) that your array is initialized and runs from 0x7F00 to 0xBFFF, you can just reference that with like zero overhead. When you add checks, there's overhead. Thus, on principle, safe code is slower (because it checks). But as you correctly pointed out, these checks are basically zero-cost on a modern CPU. Plus Rust moves a lot of them to the compile time, so really zero cost at runtime.
Also, as the Rust compiler has taught me, safe code isn't even always about checks, it can be about writing the damn thing correctly.

Edit: About C being about 1:1 match with assembly, that also had to do with what could be proven at the time to be correct code. I mean, with all the modern features you mentioned, can you confidently run gcc -O3? You can't, because nobody was ever able to proven the output of that is mathematically correct.

[jacob]

It's hard to tell. On one hand, you can concentrate on performance more if you spend less time checking memory management. But on the other hand, C's "unsafety" may allow for some interesting hack wrt performance.
I think I'm with you when I say I expect performance in the same ballpark for a few more years. After that, yes, maybe Rust can pull some rabbits out of its hat.

Many people seem to believe that safe code is somehow detrimental to performance or that a lower level language allows for some performance-improving "hacks". That's not necessarily true at all. A strong type system, together with borrow checking, lifetime analysis etc. can enable the compiler to perform some optimisations that are not readily feasible in C, like implicit destructuring, memory access reordering etc. Back when C was created, the primary goal was not performance but the ease to write and/or port a compiler. There was basically a 1-to-1 match between a C source code and the generated assembly, which in turn had a 1-to-1 match to the operations actually performed by the CPU. But this is a very different world, with complex out-of-order execution, register renaming, non-intuitive memory consistency models, hardware multithreading, SIMD and/or variable length vector instructions that we would like the compiler to take advantage of automatically as appropriate, etc. In this context, a more abstract language is a performance benefit, not a hindrance.

[bug77]

Well said, but atm I still prefer the added flexibility C++ offers me, especially templates and other compile time abstractions

concerning memory safety:
virtually all issues I'm running into are due to having to interface into C APIs using raw pointers, so Rust really won't help me there

If you don't wrap all your code in unsafe blocks, Rust will at the very least give you hints about where your troubles come from.
But once again, there are experienced C or C++ programmers out there that can produce good code without too much effort. Nobody expects them ti give that up and move to the Rust side. But now there are three choices when you want to learn systems programming: C, C++ and Rust. Most newcomers will flock to Rust, simply because it's more modern.

[cl333r]

That might be overstating the case. The most recent update in this blog which minimally refreshes the existing example code, states that

"For FreeBSD, there doesn’t seem to be any active work in this space"

Do you know something more?

Jesus Christ, I noticed you know (almost?) everything and be up-to-date with everything, are you a robot or what?

[hyperchaotic]

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.

Yeap, I've spent a good part of my life looking for memory leaks and memory issues in general in C code and in C++ code. I worked for a big C++ operation once and it was painful and costly if a memory issue showed up - they were often sporadic due to race conditions in our heavily async and threaded code and sometimes almost impossible to reproduce from a customer bug report.. We spent a lot of time developing advanced debug and memory tracking shims that would insert themselves on DLLs to track allocations/deallocs/etc.

Rust has more time spent making it compile (though it takes less and less time as the developer becomes more seasoned) but much more time saved in the testing phase and in deployment issues.

[bug77]

Don't get me wrong: there will also be performance *benefits* to using rust over C.

But it's going to take a fair bit longer for that particular advantage to materialize. Lots of compiler bugs to fix and infrastructure to build.

It's hard to tell. On one hand, you can concentrate on performance more if you spend less time checking memory management. But on the other hand, C's "unsafety" may allow for some interesting hack wrt performance.
I think I'm with you when I say I expect performance in the same ballpark for a few more years. After that, yes, maybe Rust can pull some rabbits out of its hat.

[Developer12]

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.

Don't get me wrong: there will also be performance *benefits* to using rust over C.

But it's going to take a fair bit longer for that particular advantage to materialize. Lots of compiler bugs to fix and infrastructure to build.

[oiaohm]

Linus tried C++ once 30 years ago and he decided C++ is a very bad language for kernels. He might have been right then, but things have changed a lot over the last three decades. No, nobody is going to use any runtime features in a kernel, such as exceptions, virtual functions or dynamic casts.

But still, there are many features of modern C++ that would come in handy on kernel development that will make the mantainers' lifes way easier. There are many open source operating systems (like SerenityOS) that make use of C++ features on their kernels, like the improved type safety over C, namespaces, constructors, templates (those shady and type unsafe macros should have been long gone in any kernel nowadays), RAII (the best C++ feature in my honest opinion) and they are more than happy with C++.

I don't think they are doing things wrong by using C++, like Linus once said. Should they be using pure and inmaculate C89, like Linux until a few months ago? If Rust code is accepted, modern C++ code should be as well.

Problem here is the Linux kernel is not pure C.

https://en.wikipedia.org/wiki/Sparse

Linux kernel has been C89 + Sparse extras for quite some time. Migrating to C11 means not having to implement more checking features in Sparse. Do note Linus Torvalds wrote sparse in 2003.

Migrating to C++ does not cover the issues that sparse detects. So C++ you would have to implement C++ version of sparse. Welcome to hell.

Interesting enough rust developers slide page 61

https://lpc.events/event/16/contributions/1256/attachments/1048/2003/Rust%20Status%20-%20LPC%202022.pdf

Is worth a note.

Note that direct going from rust code to Linux kernel code is totally forbid. So in the rust crate there can be sparse rules to make sure you code is not doing anything known to be stupid.

Please note sparse is also just the tip of iceberg here. You have Linux kernel added gcc plugins that check for Linux kernel known issue as well.

The Linux kernel uses a highly extended version of C. Lot of the features you say are good in C++ makes processing all the extra language limitation rules that the Linux kernel developers have added massively harder to get the same result.

[zcansi]

...

But still, there are many features of modern C++ that would come in handy on kernel development that will make the mantainers' lifes way easier. There are many open source operating systems (like SerenityOS) that make use of C++ features on their kernels, like the improved type safety over C, namespaces, constructors, templates (those shady and type unsafe macros should have been long gone in any kernel nowadays), RAII (the best C++ feature in my honest opinion) and they are more than happy with C++.

I don't think they are doing things wrong by using C++, like Linus once said. Should they be using pure and inmaculate C89, like Linux until a few months ago? If Rust code is accepted, modern C++ code should be as well.

I speak as someone who is pretty good with C (including the kernel dialect) and Rust, and has twice bounced off learning C++. I'm not strictly *against* C++ in a kernel context, but I do think you may be underestimating the degree to which Rust is different from C++ (and C). A novice can absolutely not write correct C++ in my personal experience, not even in an existing project with expertly informed coding standards and code structure. While Rust is designed from the ground up to help the compiler prevent people from making the kind of costly, hard-to-debug mistakes which people run into time and time again while learning C/C++, an then very occasionally even at the expert level. Just my personal experience, take it for whatever it's worth, but that's in my opinion a much bigger deal than the slightly improved syntax and quality of life (and, admittedly, some code patterns which help prevent some of C's problems) C++ brings.

C++ is an incremental change, Rust is a fundamental rearrangement of priorities.