Re: [hatari-devel] Hatari profiler updates and CPU cycle questions

[ Thread Index | Date Index | More Archives ]

Hi Eero,

Make sure you get the latest debugger code from Mercurial, in one
version I had signed / unsigned mismatch for cycle counter.

I am on rev #4668dded703c which appears to be the latest one.

I'm not sure what the CPU cycle counter in cycles.c does when it
wraps around, but at least with unsigned values used in profiler,
there shouldn't be negative values. :-)

I don't think it got an opportunity to wrap around in my test - it was only a few seconds long.

Something like this "shouldn't" happen with anything else
than stop instruction (or some similar instruction) now.

The same extreme value is repeated lots of times in all areas of the code (and I don't use the stop instruction at all). 

> I did play with the post processor python file and got some output but I
> think the results are invalid because the profiler output is wrong. One
> problem I did notice is that it collects statistics under symbols for
> functions which are inactive/unused. e.g.
> Executed instructions:
>  97.35%  18904938  add_upper_partition  (at 0x2210a)   <- this function
> is defined, but is never used by the test
>   1.51%    293593  HATARI_PROFILE_BEGIN

This is suspicious.  Don't you have any symbol where the execution
begins after profiling start?

The profiling was conducted from an interrupted run. The program was launched and ran for a few seconds, I interrupted it with the debugger and enabled profiling, then it was allowed to continue for a few seconds, then I interrupted again and captured the results. This was to ensure profiling took place for the mainloop only and not the texture cache initialization code (which is large and costly)
However there are plenty of symbols in the program, and the most expensive 'large' function block consumes 60% cpu in total  (i.e. my own profiler shows a different and more familiar pattern of functions) so either the symbols did not import as expected or something else has happened.

I haven't really tested profiling user code yet, just (Emu)TOS,
and a quick tests that post-processor accepts DSP disassembly.
I.e. there may be bugs still, I'll check that tomorrow.

It does seem that your results indicate the system is working, and my results look completely different!

It's probably worth trying an un-optimized build here with cycle counts to see if the compiler / code _expression_ details have anything to do with it.

Mail converted by MHonArc 2.6.19+