[HN Gopher] Inside boost::unordered_flat_map ___________________________________________________________________ Inside boost::unordered_flat_map Author : ingve Score : 45 points Date : 2022-11-18 13:37 UTC (1 days ago) (HTM) web link (bannalia.blogspot.com) (TXT) w3m dump (bannalia.blogspot.com) | 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)