[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