Latency benchmarks

[GoldsteinE]

Hi! It would be interesting to see comparison of time to hash a short string (like in aHash README). Throughput is great, but since in many cases hashmap keys are short strings, time to hash 40 KB of data is less relevant then time time to hash some e.g. 16-byte strings. Plot of hashing time per key size would be really helpful IMO.

[ogxd]

Hi @GoldsteinE!

This is exactly what is shown in the benchmarks https://github.com/ogxd/gxhash?tab=readme-ov-file#benchmarks.

What is displayed is throughput per input size. Throughput is just another way of viewing the performance. Throughput is in MiB/s, so if you want "latency", you can compute it from throughput. For instance, if we have a throughput of 8000 MiB/s for inputs of size 4 bytes, it means each 4 bytes hash takes 4 / 1014 / 1024 / 8000 s to compute or 4.8 nanoseconds.

I prefer talking in terms of throughput but if you prefer timings per hash you already have everything you need (without having to compute it from throughput):

• The throughput_criterion bench shows both throughput and timings per hash (or iteration if you prefer) for each input size. This bench uses the hash function directly, which does not know in advance about the input size.
• The hashshet bench shows the timings per hash for several string size but also some integer types. Integers size is known in advance so the Hash can use fewer steps a thus is a little performant than using the hash function directly in that situation.

Fyi there are some heavy changes ongoing https://github.com/ogxd/gxhash/issues/34 https://github.com/ogxd/gxhash/issues/44 so for now I recommend taking benchmark results with a grain of salt.

[GoldsteinE]

HashSet bench looks interesting, thanks! What I meant is “benchmarks on the small inputs” (as far as I understand, benchmarks in readme are on 40KB inputs, which is a pretty rare case for a HashMap).

[ogxd]

as far as I understand, benchmarks in readme are on 40KB inputs

No, the input size is on the X-axis. It ranges from 4 bytes to 32768 bytes.

[GoldsteinE]

Oh, sorry then, I misread the plot. Thanks again!

[ogxd]

Np! Here is the same bench but tweaked to output time per hash (and with a log scaling on the Y axis). It is maybe closer to what you expected in the first place. These are the results for my MacBook pro M1

[chamoretto]

Np! Here is the same bench but tweaked to output time per hash (and with a log scaling on the Y axis). It is maybe closer to what you expected in the first place. These are the results for my MacBook pro M1

How did you get results under 1ns? At my intel 1235u i get results not lower then 500ns. Maybe we have different code changes? My cnahges is just processor.on_result(len, throughput); -> processor.on_result(len, average_duration_s * 1_000_000_000.0); (because average_duration_s = 0.0000005161750103319448 = 516ns) and enabling log scale at result_processor, but I get completely different numerical results and slightly different shapes of the curves.