Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • linner
    replied
    Originally posted by mdedetrich View Post
    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
    Code:
    $ rustc -O hashtest.rs
    $ D=1 time ./hashtest
    11.22 elapsed 8278384 maxresident
    C++ version
    Code:
    $ 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
    Code:
    $ 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

    Leave a comment:


  • birdie
    replied
    Originally posted by mdedetrich View Post

    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.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by birdie View Post

    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.
    Last edited by mdedetrich; 11 September 2021, 09:46 AM.

    Leave a comment:


  • birdie
    replied
    Originally posted by mdedetrich View Post

    This is bullshit
    This doesn't sound like a proper counterargument.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by linner View Post
    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

    Originally posted by linner View Post
    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?

    Leave a comment:


  • linner
    replied
    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.

    Leave a comment:


  • TheMightyBuzzard
    replied
    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.

    Leave a comment:


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

    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?pa...e-BO-Detection
Working...
X