John Levon wrote:
> On Mon, Aug 18, 2003 at 11:04:33AM -0400, graydon hoare wrote:
>>oh, neat! yes, a couple:
> It's going to take some effort to make an interface like this
> "naturally" usable I think.
>> events, similar to the event definition file you already have, so
>> that people can say --analysis=L2-hit-miss-ratio
One needs to be a careful with ratios. The ratios can be misleading. I
did some experiments with gcc. I found that the better quality code had
worse cache miss ratio because the redundant memory references cached
really well. The overall number of memory references decreased in the
optimized code, but the cacheable ones were removed more effectively by
the optimizer, causing the ratio to worsen. However, in terms of
absolute performance it was improved.
> A nice idea and some away towards our implicit "provide information not
> just data" goal.
> One low-tech approach would be a cookbook section in the manual
> discussing common cases like "How do I profile cache misses on the
> Pentium IV" ?
Yes, having a cookbook section of the manual describing how look for
common problems, e.g. excessive memory references and cache misses,
would be good. Once we have some reasonable combinations we can automate
it and have bindings. One difficulty with the oprofile data is that it
can provide some very nice data about the machine code metrics. However,
for some things it might be difficult for the developer to do much about
it at the source level, e.g. changing the compiler's instruction
selection or instruction scheduling.
>>continue.. I wouldn't bother worrying about compatibility with the
>>python wrapper. it's small and if anyone *really* wants it I can
>>easily revive/revise it.
> A powerful set of bindings would be nice at some point, but
> compatibility is of absolutely zero concern to me until our 1.0 release.
> The 1.0 branch will maintain API compatibility (though probably not ABI
> compatibility) unless that requirement conflicts with fixing a
> significant bug.