Thread-safe profiling

Seongbae Park seongbae.park@gmail.com
Thu Mar 15 17:53:00 GMT 2007


On 3/15/07, Jan Hubicka <hubicka@ucw.cz> wrote:
> > Hi,
> >
> > On Thu, 15 Mar 2007, Jan Hubicka wrote:
> >
> > > Well, on the other hand number of threaded applications is definitly on
> > > a rise and the profile mismatches are evil.
> > >
> > > Perhaps we should bite the bullet and make thread safe profiling a
> > > default on targets that support it. At least that is what other
> > > compilers does.
> >
> > Not anymore.  The newest ICC doesn't do thread-safe profiling anymore.
> > But that shouldn't hinder us.
>
> Well, thinking about it - making thread-safe profiling a default for
> targets defining appropriate builtins seems best choice for me.  We will
> get the new infrastructure tested and if we get enough negative
> feedback, we can always change the default safely later in release
> series.
>
> Trying to imagine what random user would find more discourgrating - ie
> longer train runs (still probably quite shorter than in ICC) or weird
> looking mismatches and/or wrong resulting profile, I guess the former is
> lesser evil and easier to analyze.
>
> The patch would be fine even without the change (I can make it
> incrementally), but if you get into it, please also disable the thread
> safe profiling for profiledbootstrap - it is slow enough already ;)
>
> Honza

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

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.

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

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).
-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"



More information about the Gcc-patches mailing list