Linux 5.15 Readies More Code For Compile & Run-Time Detection Of Buffer Overflows

[phoronix]

Phoronix: Linux 5.15 Readies More Code For Compile & Run-Time Detection Of Buffer Overflows

Last week a number of patches were merged in the quest to provide the kernel with comprehensive compile-time and run-time detection of buffer overflows. Another patch series was sent out today while still for this cycle they are expected to enable the compiler warnings around array-bounds and zero-length-bounds...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.15-More-BO-Detection

[TheMightyBuzzard]

Man, I'm a pretty big fan or Rust but the core of the kernel ain't no place for larger and slower than C. A driver that ain't a bottleneck for much of anything or uses so little in the way of time/memory resources that making it more costly is no big deal? Sure. System memory allocation? Hell no.

[linner]

I don't know why Linus is letting Rust in the kernel. In the real real world it's not as fast as the fans claim. I have been looking at Rust for a few of my own projects recently and Rust just can't compete with C in terms of raw performance.

I've looked at a lot of Rust projects and their charts and such showing Rust just slightly slower than C but this has not been my experience at all. I think those other applications are bound by other constraints than just the software. Generally in high-performance code I find Rust about 2-3 times slower than equivalent C code.

Thus continues the downward spiral of software bloat. It's masked by faster and faster computers but is just bad design.

[mdedetrich]

I don't know why Linus is letting Rust in the kernel. In the real real world it's not as fast as the fans claim. I have been looking at Rust for a few of my own projects recently and Rust just can't compete with C in terms of raw performance.

This is bullshit

I've looked at a lot of Rust projects and their charts and such showing Rust just slightly slower than C but this has not been my experience at all. I think those other applications are bound by other constraints than just the software. Generally in high-performance code I find Rust about 2-3 times slower than equivalent C code.

Can you name such projects?

[birdie]

This is bullshit

This doesn't sound like a proper counterargument.

[mdedetrich]

This doesn't sound like a proper counterargument.

I have already answered this elsewhere, people are re-implementing many tools originally written in C to Rust and the performance is either equal or faster. You can for example have a look at https://zaiste.net/posts/shell-commands-rust/. rip grep is an example of a tool that is quite a bit faster than normal grep (for various reasons) and fd is around 5-9 times faster than find.

And to pile onto the "its even bigger bullshit" pile, Rust is basically C with a linear type checker that validates memory management, stronger type checking and other niceties such as traits that uses the same LLVM backend as clang. In other words we are not dealing with python here, Rust is as much of a "low level" language as C is.

[birdie]

I have already answered this elsewhere, people are re-implementing many tools originally written in C to Rust and the performance is either equal or faster. You can for example have a look at https://zaiste.net/posts/shell-commands-rust/. rip grep is an example of a tool that is quite a bit faster than normal grep (for various reasons) and fd is around 5-9 times faster than find.

And to pile onto the "its even bigger bullshit" pile, Rust is basically C with a linear type checker that validates memory management, stronger type checking and other niceties such as traits that uses the same LLVM backend as clang. In other words we are not dealing with python here, Rust is as much of a "low level" language as C is.

This is a good argument, thank you.

[linner]

This is bullshit

Can you name such projects?

Whoa now, I'm not killing your first born here. Those other projects don't matter, I assume their measurements are correct. I was saying the problem they're solving is limited by external factors for example a network driver is ultimately limited by the network hardware no matter how fast the software is.

I wouldn't put too much faith in the fact that rewritten standard utilities in Rust are faster than their ancient counterparts. A lot of those tools have been around so long that people take for granted that they're written well. In fact often they are poorly coded using outdated programming methods. Anyway, that's not my point.

Try the attached examples. This is just C++ vs Rust. The C++ version is not well optimized but can be sped up some with the "fmt" library. The naive C++ version is still faster than Rust and Rust uses twice(!) as much memory (probably my fault?). Go ahead, try different string hashing methods in Rust. I tried all I could find and none were faster than just using the default but if you find a better one I surely want to use it.

But that's just the beginning. My C version (not attached here) is nearly twice as fast as the Rust version so you can see why I think Rust lags here.

Some numbers:

Rust

$ rustc -O hashtest.rs
$ D=1 time ./hashtest
11.22 elapsed 8278384 maxresident

C++ version

$ g++ -DUSE_FMT -Wall -O2 -s -Ifmt/include hashtest.cpp -o hashtest fmt/build/libfmt.a
$ D=1 time ./hashtest
6.90 elapsed 4549176 maxresident

C version

$ gcc -Wall -O2 -s hashtest.c hashmap.c -o hashtest
$ D=1 time ./hashtest
5.86 elapsed 4234748 maxresident

Show me how to make the Rust version run as fast as even the C++ version and that will be a good start.

Code (we can't use attachments here?)
C++ and Rust

[birdie]

Code (we can't use attachments here?)

Michael never enabled them to save on database backups. Once you enable attachments people immediately start posting (duplicating) stupid low-quality pictures from the web.

[mdedetrich]

Whoa now, I'm not killing your first born here. Those other projects don't matter, I assume their measurements are correct. I was saying the problem they're solving is limited by external factors for example a network driver is ultimately limited by the network hardware no matter how fast the software is.

Except that again, this is not true. For the same programs, 1 to 1 Rust is either as fast or slightly faster (with the latest versions of Rust)

I wouldn't put too much faith in the fact that rewritten standard utilities in Rust are faster than their ancient counterparts. A lot of those tools have been around so long that people take for granted that they're written well. In fact often they are poorly coded using outdated programming methods. Anyway, that's not my point.

Except that Rust is sharing the same toolchain that is used for C/C++ (i.e. clang) which is backed by LLVM. This means also that any optimizations made by C/C++ in this toolchain also benefits Rust

Try the attached examples. This is just C++ vs Rust. The C++ version is not well optimized but can be sped up some with the "fmt" library. The naive C++ version is still faster than Rust and Rust uses twice(!) as much memory (probably my fault?). Go ahead, try different string hashing methods in Rust. I tried all I could find and none were faster than just using the default but if you find a better one I surely want to use it.

But that's just the beginning. My C version (not attached here) is nearly twice as fast as the Rust version so you can see why I think Rust lags here.

Some numbers:

Rust

$ rustc -O hashtest.rs
$ D=1 time ./hashtest
11.22 elapsed 8278384 maxresident

C++ version

$ g++ -DUSE_FMT -Wall -O2 -s -Ifmt/include hashtest.cpp -o hashtest fmt/build/libfmt.a
$ D=1 time ./hashtest
6.90 elapsed 4549176 maxresident

C version

$ gcc -Wall -O2 -s hashtest.c hashmap.c -o hashtest
$ D=1 time ./hashtest
5.86 elapsed 4234748 maxresident

Show me how to make the Rust version run as fast as even the C++ version and that will be a good start.

Code (we can't use attachments here?)
C++ and Rust

You are comparing completely different implementations of a HashMap, so yeah no wonder you get different results. If you look up the Rust implementation that you used, i.e. https://doc.rust-lang.org/std/collec...t.HashMap.html you will see that its a secure HashMap designed to be resilient against HashDos attacks (i.e. getting DDOS by input data deliberately designed to constantly create collisions), this of course slows down the speed of the HashMap.

There are other reasons as well which you can read about https://users.rust-lang.org/t/hashmap-performance/6476 but the tl;dr is that Rust is prioritizing safety/security as a default (which is how it should be).

If you want a more valid benchmark you can try these alternative crates that provide hashmap implementations which are not cryptographically secure or resistant against DDOS

* https://github.com/cbreeden/fxhash
* https://github.com/servo/rust-fnv

(there are others as well)

You did end up invariably pointing out another reason why C/++ is worse than Rust, they were written/designed in an age where the assumption where inputs for programs weren't publicly exposed on the internet. Of course nowadays that is very different, which is why Rust's default for datastructures are ones that are secure (where as C/C++ are not). You are always free to use another implementation, for example rust-fnv is used in the Rust compiler where they know its internal usage is not exposed to the web.