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
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 :(
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.