New Concurrent Hash Maps for C++
preshing.com
New Concurrent Hash Maps for C++
1–10 of 31 posts
Re: New Concurrent Hash Maps for C++
#2Interesting and impressive performance. The requirement to periodically halt every thread seemed like a bit of a downer though. Am I reading that wrong?
Re: New Concurrent Hash Maps for C++
#3How much overhead does std::mutex add in the single-threaded case for std::map? Because its kinda curious that this new map is more than twice as fast as std::map even on single thread.
Re: New Concurrent Hash Maps for C++
#4How much overhead does std::mutex add in the single-threaded case for std::map? Because its kinda curious that this new map is more than twice as fast as std::map even on single thread.
std::map is a RB tree, not a hash map.
Re: New Concurrent Hash Maps for C++
#5Those results look slightly suspicious to me, in that I've seen TBB concurrent_hash_map scale much better than that...
I guess it depends on the workload ratio...
Would have been nice to see a binned/sharded hashmap in the results as well, I've seen pretty good scalability on those as well.
Re: New Concurrent Hash Maps for C++
#6How much overhead does std::mutex add in the single-threaded case for std::map? Because its kinda curious that this new map is more than twice as fast as std::map even on single thread.
std::map is a RB tree, not a hash map.
I'd be interested in the answer for std::unordered_map, then.
Re: New Concurrent Hash Maps for C++
#7Interesting and impressive performance. The requirement to periodically halt every thread seemed like a bit of a downer though. Am I reading that wrong?
That seems to be the case, I do wish they'd made this requirement clear up front. There is no getting around sychronised quiescence being a blocking event, but in this case they essentially hope that either 1) you're already using a kind of scatter gather thread model like the mentioned game example - which implies an iterative discrete world, or 2) the set of threads (or tasks) interacting with the collection is simply bounded and sychronised, and/or 3) the performance is still better in aggregate even with infrequent world blocking events.
Re: New Concurrent Hash Maps for C++
#8I hope that the usage will be easier than for Intel TBB. If you are not using a mainstream build tool, then Intel TBB is a headache.
Re: New Concurrent Hash Maps for C++
#9Uhm... The absolute Y-position of the curve on the graph is secondary to its shape. Also, the scalability discussion is largely pointless if the sample set covers only 6 CPUs.
Intel TBB scales proportionally, which is precisely what you'd want here. Junction starts to flatten out on 6th CPU, which implies that it has fundamental design issues that crop up at higher CPU counts. Chances are that its performance not only won't scale further, but will actually drop further down the graph.
On other hand TBB code can be put throught some routine code optimization (hand-coded assembly and such) to increase its performance without affecting its linear graph shape.
Re: New Concurrent Hash Maps for C++
#10How much overhead does std::mutex add in the single-threaded case for std::map? Because its kinda curious that this new map is more than twice as fast as std::map even on single thread.
Overhead of std::mutex depends a lot on contention patterns. Assuming one x86 CPU socket, usually you can take + release an ideally optimized contended mutex about 10M-25M times per second, if that's all you do, 100% CPU usage on all cores. That's simply limited by how many times you can run contested LOCK XADD (x86 atomic fetch-and-add) / LOCK CMPXCHG* (x86 atomic compare-and-swap) instructions per second.
Mutex generates a lot of cache coherency traffic and saturates the CPU internal ring bus. NUMA case it'll of course quickly saturate lower bandwidth CPU external QPI link(s).
Contested mutexes perform a lot better on a typical laptop than on a server.