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

[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.

[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.

[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?

[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.

[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]

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.

[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.

[brad0]

FreeBSD is starting to look at using Rust for kernel drivers too:

https://wiki.freebsd.org/Rust#Rust_i...FreeBSD_Kernel

That's reading way too much into a Wiki page that in itself says nothing. There is nothing going on and nothing will when there isn't even a Rust compiler with the OS.

[Developer12]

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.

That's wrong. Rust's memory checking has ZERO effect on it's performance.
All of it is done at compile-time and none of it is done during run-time.

What I'm talking about are compiler optimizations which are *impossible* with C and C++ because their memory ordering semantics are literal bullshit. Unfortunately, because compilers are designed for C/C++ these optimizations are often buggy even when rust makes them possible, due to lack of testing. It's going to take years before all those LLVM/GCC bugs are fixed.

[cardich]

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

Rust is more of a "vanity project" than a concept.