From 4584e479656a97d13503fb49a8e0bc85e32b5257 Mon Sep 17 00:00:00 2001 From: greg Date: Sun, 31 Mar 2019 16:41:49 -0400 Subject: [PATCH] update writeup --- html/parallel_hashmap.md | 16 ++++++++-------- index.html | 12 +++++++++++- 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/html/parallel_hashmap.md b/html/parallel_hashmap.md index f63566a..bb3d1fb 100644 --- a/html/parallel_hashmap.md +++ b/html/parallel_hashmap.md @@ -54,14 +54,14 @@ providing an index between 0 and 15. The benefit of this approach would be that the internal tables would each resize on its own when they reach 87.5% capacity, and since each table contains approximately one sixteenth of the values, the memory usage peak would be only one sixteenth of the size we saw for the single *flat_hash_map*. The rest of this article describes my implementation of this concept that I have done in my [parallel hashmap](https://github.com/greg7mdp/parallel-hashmap) repository. This is a header only library, which provides the following eight hashmaps: - - phmap::flat_hash_set - - phmap::flat_hash_map - - phmap::node_hash_set - - phmap::node_hash_map - - phmap::parallel_flat_hash_set - - phmap::parallel_flat_hash_map - - phmap::parallel_node_hash_set - - phmap::parallel_node_hash_map + - phmap::flat_hash_set + - phmap::flat_hash_map + - phmap::node_hash_set + - phmap::node_hash_map + - phmap::parallel_flat_hash_set + - phmap::parallel_flat_hash_map + - phmap::parallel_node_hash_set + - phmap::parallel_node_hash_map This implementation requires a C++11 compatible compiler, and provides full compatibility with the std::unordered_map (with the exception of *pointer stability* for the `flat` versions. C++14 and C++17 methods, like `try-emplace`, are provided as well. The names for it are *parallel_flat_hash_map* or *parallel_flat_hash_set*, and the *node* equivalents. These hashmaps provide the same external API as the *flat_hash_map*, and internally use a std::array of 2**N *flat_hash_maps*. diff --git a/index.html b/index.html index 5b360a3..e5cad44 100644 --- a/index.html +++ b/index.html @@ -137,7 +137,17 @@

index_computation

The benefit of this approach would be that the internal tables would each resize on its own when they reach 87.5% capacity, and since each table contains approximately one sixteenth of the values, the memory usage peak would be only one sixteenth of the size we saw for the single flat_hash_map.

-

The rest of this article describes my implementation of this concept that I have done in my parallel hashmap repository. This is a header only library, which provides the following eight hashmaps: - phmap::flat_hash_set - phmap::flat_hash_map - phmap::node_hash_set - phmap::node_hash_map - phmap::parallel_flat_hash_set - phmap::parallel_flat_hash_map - phmap::parallel_node_hash_set - phmap::parallel_node_hash_map

+

The rest of this article describes my implementation of this concept that I have done in my parallel hashmap repository. This is a header only library, which provides the following eight hashmaps:

+

This implementation requires a C++11 compatible compiler, and provides full compatibility with the std::unordered_map (with the exception of pointer stability for the flat versions. C++14 and C++17 methods, like try-emplace, are provided as well. The names for it are parallel_flat_hash_map or parallel_flat_hash_set, and the node equivalents. These hashmaps provide the same external API as the flat_hash_map, and internally use a std::array of 2**N flat_hash_maps.

I was delighted to find out that not only the parallel_flat_hash_map has significant memory usage benefits compared to the flat_hash_map, but it also has significant advantages for concurrent programming as I will show later. In the rest of this article, we will focus on the parallel_flat_hash_map, but similar results are seen for the parallel_node_hash_map, and the set versions of course.

The Parallel Hashmap: memory usage