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...