On 10/04/2016 11:45 AM, Richard Biener wrote:
> On Thu, Sep 15, 2016 at 12:00 PM, Martin Liška <mli...@suse.cz> wrote:
>> On 09/07/2016 02:09 PM, Richard Biener wrote:
>>> On Wed, Sep 7, 2016 at 1:37 PM, Martin Liška <mli...@suse.cz> wrote:
>>>> On 08/18/2016 06:06 PM, Richard Biener wrote:
>>>>> On August 18, 2016 5:54:49 PM GMT+02:00, Jakub Jelinek <ja...@redhat.com> 
>>>>> wrote:
>>>>>> On Thu, Aug 18, 2016 at 08:51:31AM -0700, Andi Kleen wrote:
>>>>>>>> I'd prefer to make updates atomic in multi-threaded applications.
>>>>>>>> The best proxy we have for that is -pthread.
>>>>>>>> Is it slower, most definitely, but odds are we're giving folks
>>>>>>>> garbage data otherwise, which in many ways is even worse.
>>>>>>> It will likely be catastrophically slower in some cases.
>>>>>>> Catastrophically as in too slow to be usable.
>>>>>>> An atomic instruction is a lot more expensive than a single
>>>>>> increment. Also
>>>>>>> they sometimes are really slow depending on the state of the machine.
>>>>>> Can't we just have thread-local copies of all the counters (perhaps
>>>>>> using
>>>>>> __thread pointer as base) and just atomically merge at thread
>>>>>> termination?
>>>>> I suggested that as well but of course it'll have its own class of issues 
>>>>> (short lived threads, so we need to somehow re-use counters from 
>>>>> terminated threads, large number of threads and thus using too much 
>>>>> memory for the counters)
>>>>> Richard.
>>>> Hello.
>>>> I've got written the approach on my TODO list, let's see whether it would 
>>>> be doable in a reasonable amount of time.
>>>> I've just finished some measurements to illustrate slow-down of 
>>>> -fprofile-update=atomic approach.
>>>> All numbers are: no profile, -fprofile-generate, -fprofile-generate 
>>>> -fprofile-update=atomic
>>>> c-ray benchmark (utilizing 8 threads, -O3): 1.7, 15.5., 38.1s
>>>> unrar (utilizing 8 threads, -O3): 3.6, 11.6, 38s
>>>> tramp3d (1 thread, -O3): 18.0, 46.6, 168s
>>>> So the slow-down is roughly 300% compared to -fprofile-generate. I'm not 
>>>> having much experience with default option
>>>> selection, but these numbers can probably help.
>>>> Thoughts?
>>> Look at the generated code for an instrumented simple loop and see that for
>>> the non-atomic updates we happily apply store-motion to the counter update
>>> and thus we only get one counter update per loop exit rather than one per
>>> loop iteration.  Now see what happens for the atomic case (I suspect you
>>> get one per iteration).
>>> I'll bet this accounts for most of the slowdown.
>>> Back in time ICC which had atomic counter updates (but using function
>>> calls - ugh!) had a > 1000% overhead with FDO for tramp3d (they also
>>> didn't have early inlining -- removing abstraction helps reducing the number
>>> of counters significantly).
>>> Richard.
>> Hi.
>> During Cauldron I discussed with Richi approaches how to speed-up ARCS
>> profile counter updates. My first attempt is to utilize TLS storage, where
>> every function is accumulating arcs counters. These are eventually added
>> (using atomic operations) to the global one at the very end of a function.
>> Currently I rely on target support of TLS, which is questionable whether
>> to have such a requirement for -fprofile-update=atomic, or to add a new 
>> option value
>> like -fprofile-update=atomic-tls?
>> Running the patch on tramp3d, compared to previous numbers, it takes 88s to 
>> finish.
>> Time shrinks to 50%, compared to the current implementation.
>> Thoughts?
> Hmm, I thought I suggested that you can simply use automatic storage
> (which effectively
> is TLS...) for regions that are not forked or abnormally left (which
> means SESE regions
> that have no calls that eventually terminate or throw externally).
> So why did you end up with TLS?


Usage for TLS does not makes sense, stupid mistake ;)

By using SESE regions, do you mean the infrastructure that is utilized
by Graphite machinery?


> Richard.
>> Martin
>>>> Martin
>>>>>>      Jakub

Reply via email to