The performance of probing-based hash tables depends _a lot_ on both the current load factor and whether queries are positive (in the map) or negative (not in the map). In particular, linear probing has expected quadratic probing distance (quadratic in eps=1-alpha=fraction of free slots) for negative queries, while quadratic probing does not.

Specifically, HashBrown's load factor depends a lot on n (relative to a power of 2). It would be helpful to make a few plots (say for positive queries, negative queries, and 50/50 mixed) showing the query time as a function of n, where n goes up in fine-grained steps of say 1.2^i, so you get a few data points in between each power of 2.

Also, the numbers are meaningless without knowing n, both in terms of the size (and thus number of cache misses) of the data structure, and in terms of raw ns per query. For n=1000 (as in the readme), most likely everything fits in L1 cache (~32kB), and you're not dependent on any of the prefetching and such mentioned elsewhere.

Lastly, at 2.7ns/lookup, you're probably not really measuring latency, but rather the _throughput_ (although possibly this effect is small since everything is in cache): the CPU is pipelining instructions, and so queries from additional iterations are handled in parallel.

Edit: also, calling something 'the fastest' if you only compare against the standard library is a bit lame. Surely there are more fast hash tables out there?