search for: atomic_uint64_t

Displaying 3 results from an estimated 3 matches for "atomic_uint64_t".

Did you mean: atomic_uint32_t
2017 Mar 01
2
[lld] We call SymbolBody::getVA redundantly a lot...
...ue, Feb 28, 2017 at 12:10 PM, Rui Ueyama <ruiu at google.com> wrote: > I don't think getVA is particularly expensive, and if it is not expensive > I wouldn't cache its result. Did you experiment to cache getVA results? I > think you can do that fairly easily by adding a std::atomic_uint64_t to > SymbolBody and use it as a cache for getVA. > You're right, caching it didn't have any significant effect (though I wasn't measuring super precisely ). I think I was remembering the profile wrong. I remember measuring that we had some very bad cache/TLB misses here, but I g...
2017 Feb 28
4
[lld] We call SymbolBody::getVA redundantly a lot...
tl;dr: it looks like we call SymbolBody::getVA about 5x more times than we need to Should we cache it or something? (careful with threads). Here is a link to a PDF of my Mathematica notebook which has all the details of my investigation: https://drive.google.com/open?id=0B8v10qJ6EXRxVDQ3YnZtUlFtZ1k There seem to be two main regimes that we redundantly call SymbolBody::getVA: 1. most
2017 Mar 01
2
[lld] We call SymbolBody::getVA redundantly a lot...
...ruiu at google.com> wrote: >> >>> I don't think getVA is particularly expensive, and if it is not >>> expensive I wouldn't cache its result. Did you experiment to cache getVA >>> results? I think you can do that fairly easily by adding a >>> std::atomic_uint64_t to SymbolBody and use it as a cache for getVA. >>> >> >> >> You're right, caching it didn't have any significant effect (though I >> wasn't measuring super precisely ). I think I was remembering the profile >> wrong. I remember measuring that we ha...