From 85083af90776a96a1b19ddd679fa43e9b096a326 Mon Sep 17 00:00:00 2001 From: greg Date: Sun, 3 Mar 2019 10:47:31 -0500 Subject: [PATCH] Update README.md --- README.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 17d5bb7..63cb80d 100644 --- a/README.md +++ b/README.md @@ -179,8 +179,9 @@ When running in multi-threaded mode (in this case eight threads), potentially as Still, this is a pretty good result, we are now inserting values into our parallel_hash_map three times faster than we were able to do using the flat_hash_map, while using a lower memory ceiling. +### In Conclusion - +We have seen that the novel parallel hashmap approach, used withing a single thread, provides significant space advantages, with a very minimal time penalty. When used in a multi-thread context, the parallel hashmap still provides a significant space benefit, in addition to a time benefit by drastically reducing (or even eliminating) lock contention when accessing the parallel hashmap. ### Thanks @@ -192,5 +193,9 @@ I would like to thank Google's Matt Kulukundis for his excellent presentation of [github repository for the benchmark code used in this paper](https://github.com/greg7mdp/parallel-hashmap) +[Swiss Tables doc](https://abseil.io/blog/20180927-swisstables) + [Google Abseil repository](https://github.com/abseil/abseil-cpp) +[Matt Kulukindis: Designing a Fast, Efficient, Cache-friendly Hash Table, Step by Step](https://www.youtube.com/watch?v=ncHmEUmJZf4) +