Compile with -fno-omit-frame-pointer on x86_64?

[Owen Taylor]

On Wed, 2010-11-03 at 21:11 +0100, Jakub Jelinek wrote:
> On Wed, Nov 03, 2010 at 04:10:30PM -0400, Adam Jackson wrote:
> > On Wed, 2010-11-03 at 19:58 +0100, Jakub Jelinek wrote:
> > > On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote:
> > > > Basically summarizes the situation, and as far as I know nothing has
> > > > changed ... with default compilation options, getting callgraph
> > > > profiling on x86_64 really requires a DWARF unwinder in the kernel.
> > > > Which seems unlikely to happen.
> > > 
> > > But that's the right thing to do.
> > 
> > Sure, but so is a kernel debugger, and it's taken us over ten years to
> > get one.  I'm pretty okay with doing something wrong now if it gets me
> > something usable for long enough to get something right later.  I'll
> > take 4% across the board if it helps me find the 20% that matters.
> 
> Most of the time you don't find the 20% improvements with profilers though,
> so all we end up with is just slowing everything by 4%.  Definitely a bad
> idea, now that per core performance doesn't increase very much and most
> programs aren't parallelized at all or just very badly.

I would agree that it would be extraordinarily hard to use a profiler to
identify a code change you could make in glibc to make a non-trivial
program 4% faster.

But usually what you want a profiler for is to be able to efficiently
identify the hot spots and do 10 or so 1% changes in a row. And we also
work on a lot of code bases that are a lot less mature an tuned than
glibc. Usually, what we are trying to do is not to figure out the
function we could rewrite with a clever algorithm to do the same thing
faster; we are trying to find out the stuff we are doing that we
shouldn't be doing at all.

The other argument for profiling is that in many cases you want to ask
someone else to get a profile of a situation that is slow for them, that
maybe isn't slow for you. When things are *massively* slow, then it's
pretty easy for me to track that down using top to identify the
massively slow process, and attaching to it with gdb. But it's not
something that's easy to guide someone through over IRC.

I'm sure you wouldn't claim that Fedora as an operating system is within
4% of how fast it could be, or that our most efficient way of making
Fedora faster is compiler optimization :-)

- Owen

[ But yes, 4% is a big hit. 1% I would accept without hesitation.
  4% does make me hesitate a little bit. During devel cycles, we
  accept much more slowdown than that for the debug kernel, 
  of course. If we can figure out profiling without frame
  pointers, that would be even better ]