[Openmp-commits] [PATCH] D123446: [OpenMP][FIX] Remove shadow pointer map and introduce consistent locking

Shilei Tian via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Wed Apr 13 13:04:38 PDT 2022


tianshilei1992 added inline comments.


================
Comment at: openmp/libomptarget/include/device.h:92
+    /// pointer addresses to identify stale entries.
+    std::map<void **, ShadowPtrInfoTy> ShadowPtrInfos;
 
----------------
jdoerfert wrote:
> tianshilei1992 wrote:
> > jdoerfert wrote:
> > > tianshilei1992 wrote:
> > > > We don't use the order here, right? If so, `unordered_map` can usually get better performance.
> > > We do not use the order, correct. I can change it though I doubt it makes much of a difference.
> > Would be better to do it. https://stackoverflow.com/questions/36392583/is-an-unordered-map-really-faster-than-a-map-in-practice
> That comparison is not helpful. Our expected size is *probably* < 10.
It also says:
> TL;DR
> 
> Results: the unordered_map shows its superiority as soon as there is data in the map. The only time it exhibits worse performance than the ordered map is when the maps are empty.
The answer also shows the search speed is different, not just insertion speed.

Actually, based on all the uses of `ShadowPtrInfos`, it doesn't have to be a map at all because we never need the key-value relation. It can be simply an `unordered_set<ShadowPtrInfoTy>` hashed by `ShadowPtrInfoTy::HstPtrAddr`. The only place we need the "hash" feature is when adding an element.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123446/new/

https://reviews.llvm.org/D123446



More information about the Openmp-commits mailing list