|[hatari-devel] Re: hatari profiler CPU cycles questions|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On maanantai 28 tammikuu 2013, Douglas Little wrote:
> So the puzzle remains - how can two sequential (and trivial) instructions
> have such variant cycle counts - 68100... 6... when cache misses are not
> involved in the sum and the instructions are only ever visited together?
> Even given my misunderstanding so far, there still must be something
> wrong there. "clr.l d0" can not average to 68100 cycles under any normal
> conditions, and "move.w 0(a0)" can't sum to 6 cycles (had it been a
I CC this to hatari-devel, there might be some issue in using
Cycles_GetCounter(<cpu>) in WinUAE do_specialities().
> *$1493c8 : 52b9 0014 c014 addq.l #1,$14c014
> 0.05% (11346, **38334, 17272**)*
> $1493ce : 206e 0018 movea.l $18(a6),a0
> 0.05% (11346, 113476, 2)
> $1493d2 : 4280 clr.l d0
> 0.05% (11346, 68100, 2)
> $1493d4 : 302a 0000 move.w 0(a2),d0
> 0.05% (11346, 6, 7825)
> I probably can't spend much more time with it today but will return to it
> tomorrow in case I can find a reason for this unusual result. There are
> interrupts running in BadMood including a sampling profiler interrupt.
> I'll disable that in case it has been visiting the same addresses over
> and over through bad luck or a weird emulation granularity effect....
If that doesn't explain it, I don't think it makes sense in spending much
time in debugging cycles accuracy. Cache missses are missing from cycles,
the values are mostly averages etc. Better to look more into instruction
and cache miss counts. :-)