Re: some profiling numbers

[Daniel Berlin <dberlin at dberlin dot org>]

On Wednesday, June 25, 2003, at 1:39 PM, graydon hoare wrote:

> hi,
>
> I've recently done some profiling and analysis of gcc and g++, using 
> the oprofile hardware-assisted profiling module in linux 2.5. I 
> collected stats on a variety of versions of gcc (some only of 
> historical interest) and some different branches and workloads, and 
> characterized some aspects of the cache and branch-mispredict 
> penalties in addition to cycle hotspots.
>
> the results of the work are posted at
>      http://people.redhat.com/graydon/gcc-optimizing/
>  and http://people.redhat.com/graydon/g++-report/
>
> any comments or questions are welcome (including instructions and 
> hand-holding on how to set up the profiler for your own runs, if you 
> want to do more of this stuff).


Errr, one problem i have with the G++ report  is that it doesn't deal 
with macros.

Note it says pool_alloc has increased it's share of the runtime, but 
there is no corresponding decrease in some other function.

This is simple to explain: All things replaced by pool_alloc were 
previously using obstack_alloc, which is a macro.
Thus, it won't show up, at all.

The statement that "this result is not terribly encouraging; as in our 
previous analysis of gcc, it appears that there have been more general 
slowdowns than speedups between "3.4" and "3.5" (though neither of 
these versions is finalized yet). using the opreport tool we see that 
this is in fact the case:" doesn't account for things like this.

> -graydon