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 ] -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
