llvm dev - Jun 2017 - Enable STATISTIC all the time again?

On Wed, May 31, 2017 at 10:44:01AM -0700, Tim Northover via llvm-dev
wrote:
> On 31 May 2017 at 08:17, Daniel Berlin via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > If your concern is the atomic increments, then is there a reason to
not have
> > it do the counting as a runtime option instead of a compile time one?
> 
> Or increment into TLS variables and sum those at the end. Looking at a
> statistic before the end of execution is dodgy territory anyway, but I
> can't think of a case where it would be saner if other threads are
> poking at it simultaneously.
Access to TLS variables can easily be more expensive than any atomics...

Joerg

On 31 May 2017 23:15, "Joerg Sonnenberger via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:

On Wed, May 31, 2017 at 10:44:01AM -0700, Tim Northover via llvm-dev
wrote:
> On 31 May 2017 at 08:17, Daniel Berlin via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > If your concern is the atomic increments, then is there a reason to
not
have
> > it do the counting as a runtime option instead of a compile time one?
>
> Or increment into TLS variables and sum those at the end. Looking at a
> statistic before the end of execution is dodgy territory anyway, but I
> can't think of a case where it would be saner if other threads are
> poking at it simultaneously.
Access to TLS variables can easily be more expensive than any atomics...


Hi,

Isn't stats essentially a fire and forget type of data flow.
You are saying "increase this counter" but you don't actually care
what the
value is at the time of the update.
Why can't you have thread local stats, thus not requiring any locking, and
then add all the thread local stats up at the end, once the threads have
finished?

Lockless stats collection would be fast.

If you happened to need to collect stats during the run, pausing of threads
is needed. I.e. like you have when sitting on a breakpoint.

Kind regards

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170604/c3657dbd/attachment.html>

On Sun, Jun 04, 2017 at 10:09:42AM +0100, James Courtier-Dutton
wrote:
> Why can't you have thread local stats, thus not requiring any locking,
and
> then add all the thread local stats up at the end, once the threads have
> finished?
Depending on the architecture, getting the thread base register involves
a special trap or other expensive magic. At least for a single-threaded
clang, that's much more expensive than an atomic if it can't be moved
early enough and amortized aggressively by the compiler.

Joerg