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

[linner]

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.

I did look that up because I knew of that supposed "cryptographic" hash. As I stated in my post, I already tried all the various hashing algorithms and that includes Fx and Fnv. Though I did originally test using Fx and Fnv from the Hashing crate and not those projects you linked. Here are some more results from those projects:

Rust using FxHash

10.48 elapsed  8278420 maxresident

Rust using FnvHash

16.59 elapsed  8278592 maxresident

Care to try again?

Edit:
FWIW I also tried the DJB hashing algorithm with near identical implementations between C and Rust and C was way faster.

[mdedetrich]

I did look that up because I knew of that supposed "cryptographic" hash. As I stated in my post, I already tried all the various hashing algorithms and that includes Fx and Fnv. Though I did originally test using Fx and Fnv from the Hashing crate and not those projects you linked. Here are some more results from those projects:

Rust using FxHash

10.48 elapsed 8278420 maxresident

Rust using FnvHash

16.59 elapsed 8278592 maxresident

Care to try again?

Edit:
FWIW I also tried the DJB hashing algorithm with near identical implementations between C and Rust and C was way faster.

Then the issue can be a combination of the following

* AutoVectorization (i.e. https://stackoverflow.com/questions/...miss-something) which would be an issue in LLVM and not Rust specifically (it also means you are not comparing apples to apples, i.e. a more valid comparison would be using clang instead of gcc/g++ since they both share the same LLVM backend and hence you would just be testing the language frontend which is what you want). https://news.ycombinator.com/item?id=20944403 is another good read
* Rust does bound checking by default, C/C++ does not. Since you are doing index access on your arrays (i.e. when you print with

println!("{}", table[&(String::from(ENTRY) + "33000")])

) this inhibits a performance penalty (i.e. https://stackoverflow.com/questions/...ct-performance). If you use iterators then Rust doesn't do bounds checking and hence you can completely eliminate this, alternately you can compile the program without bounds checking. Again this is a safety feature since exceeding bounds on index lookup is one of the most common reasons for security/memory bugs. As a last resort you can compile without bounds checking but no one would do this and its also not idiomatic in Rust to use direct index lookup on arrays as a form of iterating through elements (everyone uses iterators instead). Using

unsafe_ref/unsafe_set

is another option which doesn't use bounds checking and is not that uncommon if accessing fixed addresses in hardware (for example).

If you want to be more scientific, then use something like https://godbolt.org/ since it lets you directly explore the assembler to see whats going on (it lets you quickly benchmark something without also benchmarking print), and also make sure you compare clang (for C/C++) with Rust and not g/g++

[pal666]

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

this is bullshit on two accounts. first, there are many c++ toolchains and only one rust toolchain. in these examples c++ toolchan was gcc, which isn't shared with llvm. second, optimizer is not magic, if your code is shit, it will be slower with same optimizer

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.

he ended up showing his priorities, which for the record i don't share. hash_map was added to c++11, i.e. it's not older than rust. and it does the right thing, because when attacker can control your inputs, you don't use some imbecilic hash_map with randomizer, you use standard map, which can't degenerate into linked list and as bonus point when you print it, you get sorted output rather than randomly shuffled on each run. i tried his test with std::map, it's still faster than rust's hash map (and rust's btree map). btw, it's bad example of c++ code, two last lines of loop body should be replaced with

rawlen += entry.size() + value.size();
a.emplace(move(entry), move(value));

it will make program faster(it was faster than rust even when doing unnecessary copy of every string)

[pal666]

AutoVectorization

bullshit excuse, he used -O2, gcc doesn't do autovectorization on -O2. (-O3 will make c++ example even faster)

Rust does bound checking by default, C/C++ does not. Since you are doing index access on your arrays (i.e. when you print with

println!("{}", table[&(String::from(ENTRY) + "33000")])

) this inhibits a performance penalty

another bullshit excuse. it's done once per program run, not once per loop iteration.

are you even a programmer?

[pal666]

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)

except that it's nothing but unsubstantiated propaganda by uneducated rust zealots

[mdedetrich]

this is bullshit on two accounts. first, there are many c++ toolchains and only one rust toolchain. in these examples c++ toolchan was gcc, which isn't shared with llvm. second, optimizer is not magic, if your code is shit, it will be slower with same optimizer

Yes exactly, which is why when you are doing comparison you should use the same toolchain which in this case is LLVM which is what clang uses, otherwise you might be revealing an issue in LLVM and not Rust (which has actually happened quite frequently)

he ended up showing his priorities, which for the record i don't share. hash_map was added to c++11, i.e. it's not older than rust. and it does the right thing, because when attacker can control your inputs

Right, so as I stated earlier we are comparing completely different algorithms and we are surprised by getting different results? What now, we are going to start comparing bubble sort with quick sort?

Rust is defaulting to a safe algorithm with a secure hash which is a sane default and is obviously slower.

What else do you want to know, the sky is blue.

you don't use some imbecilic hash_map with randomizer, you use standard map, which can't degenerate into linked list and as bonus point when you print it, you get sorted output rather than randomly shuffled on each run. i tried his test with std::map, it's still faster than rust's hash map (and rust's btree map). btw, it's bad example of c++ code, two last lines of loop body should be replaced with

No you don't, thats even worse because you are giving a false sense of security. And in case you are wondering, unordered_map is not resilient against DoS attacks https://stackoverflow.com/a/41384008

Surprise surprise, if you want to be secure then this usually means you have to be quite a bit slower and it has nothing to do with the language.

bullshit excuse, he used -O2, gcc doesn't do autovectorization on -O2. (-O3 will make c++ example even faster)
another bullshit excuse. it's done once per program run, not once per loop iteration.

are you even a programmer?

Yes and of course I know this. As a programmer I also know not to include f**ken print statements when doing a benchmark, either use ifdefines to remove the code completely when doing a benchmark or if you are lazy just the comment the code out.

This is why I recommended godbolt.

[pal666]

Yes exactly, which is why when you are doing comparison you should use the same toolchain which in this case is LLVM

no, the toolchain in this case is gcc and let rust zealots keep their mouths shut until there's a gcc rust toolchain

Right, so as I stated earlier we are comparing completely different algorithms and we are surprised by getting different results?

moron, i told you in clear text that c++ (ordered)map is faster than any rust map.

Rust is defaulting to a safe algorithm with a secure hash which is a sane default and is obviously slower.

c++ is defaulting(std::map is the default) to safe algorithm which is rbtree and which is both secure and faster than rust algorithms. and it also produces sorted results as a bonus point

What else do you want to know, the sky is blue.

i want to know when uneducated rust imbeciles will stop spreading bullshit

No you don't, thats even worse because you are giving a false sense of security. And in case you are wondering, unordered_map is not resilient against DoS attacks

imbecile, you can't parse trivial rust program and you can't parse trivial english sentence. i told you that (ordered) std::map is faster than any rust map and is resilient against dos attacks. and when you know you can't have dos attack, then you can use unordered_map in c++, which could be even faster, because it was not idiotically pessimized like rust one(rust hash map is slower than rust tree map in this case, which makes me wonder why they even included it. it could be same scheme like in any other inferior language: skip cs classes, develop map which degenerates into list, get hit by cve, paper it over with randomization)

Yes and of course I know this. As a programmer I also know not to include f**ken print statements when doing a benchmark, either use ifdefines to remove the code completely when doing a benchmark or if you are lazy just the comment the code out.

you must be programmer in kindergarden, i doubt anybody will pay such an imbecile. print statement was included to show that benchmark does its loop instead of optimizing it away. and one print statement for 400k loop iterations will not be visible in timing, there'll be much more noise from random fluctuations

This is why I recommended godbolt.

this is why i advise you to stop trying to spread bullshit among real developers

[mdedetrich]

no, the toolchain in this case is gcc and let rust zealots keep their mouths shut until there's a gcc rust toolchain

Then the benchmark is bullshit because you are comparing apples to oranges, have a nice a day

moron, i told you in clear text that c++ (ordered)map is faster than any rust map.

Don't care, the guy was clearly comparing an unordered_map to a rust HashMap

c++ is defaulting(std::map is the default) to safe algorithm which is rbtree and which is both secure and faster than rust algorithms. and it also produces sorted results as a bonus point

Good to know, also irrelevant. And now you are comparing a rbtree to a swiss table hash map which is what Rust uses by default (see https://github.com/rust-lang/rust/pull/58623)

i want to know when uneducated rust imbeciles will stop spreading bullshit

Will likely happen when imbeciles like yourself will stop making uneducated posts

imbecile, you can't parse trivial rust program and you can't parse trivial english sentence. i told you that (ordered) std::map is faster than any rust map and is resilient against dos attacks

Yes, one is faster than the other because they use different hash functions and also different hashmap implementations, who would have thought?

. and when you know you can't have dos attack, then you can use unordered_map in c++, which could be even faster, because it was not idiotically pessimized like rust one(rust hash map is slower than rust tree map in this case, which makes me wonder why they even included it. it could be same scheme like in any other inferior language: skip cs classes, develop map which degenerates into list, get hit by cve, paper it over with randomization)

Blah blah random unsubstantiated idiotic dribble blah blah

you must be programmer in kindergarden, i doubt anybody will pay such an imbecile. print statement was included to show that benchmark does its loop instead of optimizing it away. and one print statement for 400k loop iterations will not be visible in timing, there'll be much more noise from random fluctuations
this is why i advise you to stop trying to spread bullshit among real developers

So let me get this straight, you are going at me like some raging lunatic that probably thinks Rust killed his cat and LLVM is causing global warming while conveniently ignoring the various elepehant/s in the room when someone was trying to show that "C++ is faster than Rust" ergo

* They are comparing completely different implementations of hashmap with different hash functions (regardless if you are using a sorted or unsorted map, no idea why you brought up this asinine point but knowing you its because you probably wanted to derail the thread entirely). I tried to point the guy in the right direction by providing other map alternatives but it looks like he didn't even spend the 5 minutes to realize that he was comparing fundamentally different HashMap's
* Is also benchmarking printf
* Isn't even using standard iterators in Rust (admittedly this was a tidbit regarding his printf statement but in Rust you don't idiomatically directly access index's for data structures unless we are interfacing with h/w or something along those lines)
* Is using different toolchain backends

So yeah, I am sorry but you have to excuse me when I decide to not spend effort because someone clearly doesn't know they are doing and also in your case when you are trying excuse them and then do the exact same thing. Neither you or him are worth any more of my time than I spent writing these posts.