good benchmark

[ktprime]

you can move some compile marco to input line. this's easy to use.

[goldsteinn]

Which macros specifically? Have made a lot of updates to the table since making this too so I'll try and clean this up/update the table when I get the time. Lmk any changes you'd suggest in the meantime.

[ktprime]

I have collect many(8-10) thirdparty hash map bench programming in my git and one of mine
https://github.com/ktprime/emhash/blob/master/bench/ebench.cpp.

some of them is not easy to combine into one whole cpp file and only save in my pc.
can you add my hash map into your test?
https://github.com/ktprime/emhash/blob/master/hash_table5.hpp and https://github.com/ktprime/emhash/blob/master/hash_table6.hpp

[goldsteinn]

Added both tables.
https://github.com/ktprime/emhash/blob/master/hash_table6.hpp is segfaulting for me.

[ktprime]

I'll fix it, my hash map can not init with 0 bucket.

[ktprime]

I add your hash and bench code into my github https://github.com/ktprime/emhash/tree/master/bench.
there are many thirdparty bench code which can fully bench hash map performance from different case.
enjoy it.

[goldsteinn]

Thanks.

[ktprime]

no need set marcoINSERT_FAILURE_RATE(init_vals), most time the value is not effect bench result.

I have updated bench code https://github.com/ktprime/emhash/blob/master/bench/fbench.cpp
and it can easy test thirdparty hash map without use the marco in makefile.

huangyuanbing@ubuntu:~/hash$ g++ -O3 -std=c++17 -march=native fbench.cpp -o fb -lpthread && ./fb n 13456789 if 0.3

if 0.3 rf 0.2 qf 0.3 rr 0.2 qr 1 n 13456789
Total Operations: 29604935
Inserts (13456789), Failure Rate (0.350)
Querys (13456789), Failure Rate (0.300)
Removes (2691357), Failure Rate (0.250)

emhash67HashMap Perf ->
2755.760 MS 2755760254.000 NS -> 93.084 ns / op

ska13flat_hash_map Perf ->
3003.894 MS 3003894471.000 NS -> 101.466 ns / op

emhash57HashMap Perf ->
2351.194 MS 2351193817.000 NS -> 79.419 ns / op

emhash77HashMap Perf ->
2295.364 MS 2295364311.000 NS -> 77.533 ns / op

0robin_hood6detail5TableILb1ELm88EjjNS_4hash Perf ->
2152.523 MS 2152522688.000 NS -> 72.708 ns / op

phmap13flat_hash_map Perf ->
2679.680 MS 2679680440.000 NS -> 90.515 ns / op

tsl9robin_map Perf ->
2712.570 MS 2712569606.000 NS -> 91.626 ns / op

[goldsteinn]

Nice!

I think if you if you arent going to use mmap to clear cache could probably allocate something >= cache size on the heap at the begining to use and just free it after all tests. It does appear the first table to be run is at a serious disadvantage.

You also might consider adding -mtune=native as a compiler argument.

[goldsteinn]

Hmm, seems my table doesnt do so well in heavy delete benchmarks. Will have to take a look at it soon.

Edit: No it seems to be an issue with table growth, will have to take a look into how it scales. Nice benchmarks :)

[ktprime]

bug in your hash table
inline constexpr uint64_t
max_size() const {
return (1UL) << this->log_size; // this->log_incr ?
}

[goldsteinn]

That is a bug! And you have the correct fix.

Once I finish my current project I plan to refactor the table. I'll deal with that (along with a lot of other inefficiencies) then.