This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread-safe profiling

> I have mild objections to making this default:
> 1)
> Currently, given the lack of hot PRs for the lack of thread-safe profiling,
> it doesn't look like many people are trying to use gcc to use
> profile-feedback based optimization on multithreaded programs
> (gcov works just fine with slight undercounting),
> because currently it's not useable (you'll get mismatch).A

Well, we declare that profiling with threading doesn't work, so it is
not much surprise that users are not reporting it as a bug :)
Concerning the gcov, I am mostly concerned about the propagation of
errors to negative counts and such as I've mentioned in answer to Iant's

Also if I was gcov user unaware of threading issues and saw gcov
reporting obviously nonsential numbers (such as negative counts), I
would probably declare it useless ;)
> 2) Atomic counter increment hurts more as you have more threads,
> which is exactly the kind of programs this flag is supposed to help.
> This hurts using gcov on multithreaded programs
> because it will increase the coverage runtime significantly
> without significant benefit (slight undercounting is OK
> for most code coverage analysis purpose).
> 3) Making counters TLS is the long term right thing to do.

This was discussed while back (and originally implemented by Zdenek
and with TLS support is actually easier to do than the locking).
The main problem is that you have quite many counters - ie about 10MB
for gcc.  Allocatting 10MB of counters on each thread creation and
merging it in critical section on every termination is not making the
environemnt very thread friendly.
So it was decided that we should go with atomic increments instead...
> In summary, the cost of turning this on by default is
> 1) slow down of single-threaded coverage and profile-feedback runtime
> 2) slow down of multi-threaded code coverage runtime
> while the benefit is it allows multithreaded profile-feedback
> which doesn't look like it's in a hot demand (at least yet
> - I have no doubt it will be in some future).

I am really don't know how user base of gcov compare to userbase of profile
feedback.  My guess is that both userbases are relatively small

Just as an approximation, google returns 33400 matches on
-ftest-coverage, 20000 for -fprofile-use and 53000 with
-fbranch-probabilities :)
> On the other hand, this is only a mild objection
> because it's hard to tell whether there's unseen huge demand
> for this feature, and it's relatively easy to turn the default back,
> and I don't want to hold off "good" because it's not "perfect" (i.e. TLS).

Well, there is no "perfect" sadly, but I don't have very strong
objections in either direction.  Just it seems to me that we should make
our overall environment thread friendly those days.

> -- 
> #pragma ident "Seongbae Park, compiler,";

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]