[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)

[Dmitry Vyukov]

On Fri, Apr 25, 2014 at 8:30 PM, Duncan P. N. Exon Smith
<dexonsmith at apple.com> wrote:
> (Sorry to jump in before reading the whole thread...)
>
> On 2014-Apr-24, at 1:33, Dmitry Vyukov <dvyukov at google.com> wrote:
>
>> On Wed, Apr 23, 2014 at 10:48 PM, Bob Wilson <bob.wilson at apple.com> wrote:
>>> I can see that the behavior of our current instrumentation is going to be a
>>> problem for the kinds of applications that you’re looking at. If you can
>>> find a way to get the overhead down without losing accuracy
>>
>> What are your requirements for accuracy?
>> Current implementation does not provide 100% accuracy, so it's
>> something less than 100%.
>
> Modulo any bugs, my understanding is that the current implementation
> *does* provide 100% accuracy for single-threaded applications, as long
> as the counters don't overflow.  Am I missing something?


This is mostly correct. Probably modulo signals/interrupts (which can
arrive in between of increment and lead to a lose of arbitrary number
of increments -- all increments in handler itself).
But it's difficult to say what is a single-threaded app today, as lots
of libraries can create threads (it's usually not part of a contract).