|
| htfy96 wrote:
| To anybody unfamiliar with recent progress,
| boost::unordered_flat_map is the fastest open-addressing hash map
| implementation in this field for C++. Coming out just several
| months ago, it outperforms absl::flat_hash_map and various other
| implementations benchmarked in
| https://martin.ankerl.com/2022/08/27/hashmap-bench-01/.
| jeffbee wrote:
| It's a little hard to take seriously some of the top performers
| in that table, like emhash8, when the implementations are only
| a couple of weeks old and the commits are things like "fix
| crash", "fix clear", and "fix overflow".
| waynesonfire wrote:
| Uhh.. super irrelevant--being web scale is the most important
| attribute.
| no_wizard wrote:
| I think I need more context for whet you're trying to say
| here. I understand "web scale" in the marketing term Mongo
| sense but I don't know how that applies to this
| anonymoushn wrote:
| I have tried swiss tables but I have been unable to make these
| match the performance of robin hood tables with a single-stage
| lookup. Fundamentally the issue seems to be that swiss tables
| require one to read 2 or 3 cache lines while the alternative
| requires one to read only 1 cache line per lookup (most of the
| time). The included benchmarks are not that useful for inserting
| many items or looking up many items because one can achieve much
| higher throughput using prefetching (like <<10ns/op), but this
| sort of consideration never makes it into any graphs.
___________________________________________________________________
(page generated 2022-11-19 23:00 UTC) |