[Openmp-dev] Non overlapping memory segments

[Ye Luo via Openmp-dev]

That is very helpful. Currently the linear lookup is too slow. My profiling
result shows most of my time spent in lookup.
std::list and linear searching is quite bad for me. Considering std::set
which provides logarithmic complexity searching although insert/erase cost
logarithmic complexity as well.
I'm not worried about insert/erase since it is nothing compared to device
malloc/free and it can be optimized with "target enter/exit data".
Any concerns on this?
Best,
Ye
===================
Ye Luo, Ph.D.
Computational Science Division & Leadership Computing Facility
Argonne National Laboratory


On Thu, Jun 18, 2020 at 4:32 PM Rokos, Georgios <georgios.rokos at intel.com>
wrote:

> Hi Ye,
>
>
>
> Yes, it’s safe to assume so. If the user code tries to map a new memory
> region which extends into an already mapped memory region, then
> libomptarget will error out and won’t perform the new mapping. The only
> case where such an extension into already mapped data is allowed is when
> the mapping is implicit, but in that case no new mapping is created
> actually, i.e. the library reuses the existing entry in HostDataToTargetMap
> to perform address translation.
>
>
>
> George
>
>
>
> *From:* Openmp-dev <openmp-dev-bounces at lists.llvm.org> * On Behalf Of *Ye
> Luo via Openmp-dev
> *Sent:* Thursday, 18 June, 2020 06:18
> *To:* via Openmp-dev <openmp-dev at lists.llvm.org>
> *Subject:* [Openmp-dev] Non overlapping memory segments
>
>
>
> Hi all,
>
> Can I safely assume no overlapping memory segments stored in
> HostDataToTargetMap in libomptarget?
>
> Best,
>
> Ye
>
> ===================
> Ye Luo, Ph.D.
> Computational Science Division & Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200618/56564c73/attachment.html>