or Abseiling from the shoulders of giants - © Gregory Popovitch - March 3, 2019
+or Abseiling from the shoulders of giants - © Gregory Popovitch - March 10, 2019
[tl;dr] We present a novel hashmap design, the Parallel Hashmap. Built on top of Abseil's flat_hash_map, the Parallel Hashmap has lower space requirements, is nearly as fast as the underlying flat_hash_map, and can be used from multiple threads with high levels of concurrency.
If you haven't been living under a rock, you know that Google open sourced late last year their Abseil library, which includes a very efficient flat hash table implementation. The absl::flat_hash_map stores the values directly in a memory array, which avoids memory indirections (this is referred to as closed hashing).
@@ -153,7 +153,7 @@The first step (compute the hash) is the most problematic one, as it can potentially be costly. As we mentioned above, the second step (computing the index from the hash) is very simple and its cost in minimal (3 processor instruction as shown below in Matt Godbolt's compiler explorer):
As for the hash value computation, fortunately we can eliminate this cost by providing the computed hash to the submap functions, so that it is computed only once. This is exactly what I have done in my implementation pof the parallel_hash_map within the Abseil library, adding a few extra APIs to the Abseil internal raw_hash_map.h header,= which allow the parallel_hash_map to pass the precomputed hash value to the underlying hash tables.
+As for the hash value computation, fortunately we can eliminate this cost by providing the computed hash to the submap functions, so that it is computed only once. This is exactly what I have done in my implementation of the parallel_hash_map within the Abseil library, adding a few extra APIs to the Abseil internal raw_hash_map.h header, which allow the parallel_hash_map to pass the precomputed hash value to the underlying submaps.
So we have all but eliminated the cost of the first step, and seen that the cost of the second step is very minimal. At this point we expect that the parallel_hash_map performance will be close to the one of its underlying flat_hash_map, and this is confirmed by the chart below:
Indeed, because of the scale is somewhat compressed due to the longer times of the std::unordered_map, we can barely distinguish between the blue curve of the flat_hash_map and the red curve of the parallel_hash_map. So let's look at a graph without the std::unordered_map:
@@ -318,6 +318,7 @@ class parallel_flat_hash_map;Github repository for the benchmark code used in this paper
+My fork of Google Abseil repository, with the parallel_flat_hash_map implementation
Matt Kulukindis: Designing a Fast, Efficient, Cache-friendly Hash Table, Step by Step
diff --git a/htmp/parallel_hashmap.md b/html/parallel_hashmap.md similarity index 100% rename from htmp/parallel_hashmap.md rename to html/parallel_hashmap.md diff --git a/htmp/parallel_hashmap.pdf b/html/parallel_hashmap.pdf similarity index 100% rename from htmp/parallel_hashmap.pdf rename to html/parallel_hashmap.pdf diff --git a/htmp/template.html b/html/template.html similarity index 100% rename from htmp/template.html rename to html/template.html diff --git a/htmp/template.latex b/html/template.latex similarity index 100% rename from htmp/template.latex rename to html/template.latex