Performance Comparison in multithread environment: robin_hood::unordered_map vs. tbb::concurrent_hash_map

 

robin_hood::unordered_map

robin_hood::unordered_map is said to be among the fastest in replacements for std::unordered_map. Personally I found that both in VS2019 and Ubuntu 20.04 the map reduces about half of the time spent against std::unordered_map. However, considering its birth and origin, in multithreaded environment we need to serialize the access to the hashmap using something like mutex. Or, the angry Lord of Segmentation Fault will fire at you(......).

tbb::concurrent_hash_map

Well, if you're in multithreading environment, you can't avoid this: Intel's proud production, tbb::concurrent_hash_map from oneTBB (Threading Building Block). In multithreaded environment container classes from TBB is quite decent. Certainly, I'm sure Intel devoted the best efforts to TBB, as its performance is about similar to std::unordered_map, if I compare time spent for the operation.

Fastest in Single Thread vs. Optimized for Multithread

One shows the best speed in single thread environment, and the other is optimized for multithreading. Then one thing: what if we apply something like std::shared_mutex to robin_hood::unordered_map? Wouldn't it be faster if there are more read than write?

OK OK. I know it's nerdy, but you know, ....... a lot of programmers are nerds. Right? So I applied that to my current development. The program's read-write ratio is about 3:1, and I applied std::shared_mutex.

The winner? TIE(oops). The time spent for both libraries was about the same or similar.

What's Your Choice?

Anyway it depends(tm), I concluded tbb:concurrent_hash_map is better. I think tbb::concurrent_has_map will show better performance if there are more requests, and you can avoid any mistakes on implementation with with its own syntax for forced data lock.

For some time being, I'd reside on tbb::concurrent_hash_map.

One More Thing: QReadWriteLock vs. std::shared_mutex (C++17)

Oh yeah. Another nerdy test. For this I just had to swap lock/mutex only so I did it too. And unexpectedly, std::shared_mutex won this time. Though the Qt Company and the community did a lot of efforts to optimize QReadWriteLock(e.g. https://codereview.qt-project.org/c/qt/qtbase/+/140322/ and https://woboq.com/blog/qreadwritelock-gets-faster-in-qt57.html), after some years there seems to be better(and standard) alternative.

 

Yet anyway, thanks for your hard work, Qt team!