Re: [hatari-devel] Bogus profiler CPU cycles values

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On perjantai 15 helmikuu 2013, Eero Tamminen wrote:
> I found the reason for the wierd CPU cycles values in profiler.
> And why they looked OKish in my profiles, but completely bogus
> for Douglas.
> 
> It's a bit silly, I should have noticed it before.
> 
> CPU cores increase the CPU cycles counter constantly when
> DSP is NOT enabled, but give the current instruction cycles
> information when DSP IS enabled.
....
> I'd like to remove this kind of behavior changes, cycles
> counters should always behave the same way.

For now I just check for DSP being enabled in the profiler.
This hopefully fixes the main issue Douglas was having with
cycle counts:
http://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/f97aba0cd462

As we know how long CPU & DSP cycles take, with reliable
cycle information I can count emulated machine wall times
used for the cycles, that will come next.  I.e. with profiling
on, one will see exactly how much time is spent between each
breakpoint, in post-processed profile data etc.

Currently I'm showing time in seconds, with 3 decimals, is
that enough?  (It's assumed to be used with longer operations)


> I.e. I'd like to remove the if line here so that counter is
> always reset in CPU cores:
> ----
>                 /* Clear M68000 cycle counter */
>                 if (bDspEnabled)
>                         Cycles_SetCounter(CYCLES_COUNTER_CPU, 0);
> ----
> 
> As it's in the CPU main loop, it obviously has some effect
> on speed.  Compared to earlier, speed decreases a bit when DSP is
> disabled (as it now always updates CPU counter), and potentially
> increases when DSP is enabled (as there's one if less).
> 
> Comments, or objections to this?

I would still be interested on comments to this...


	- Eero