Re: [hatari-devel] DSP performance

[ Thread Index | Date Index | More Archives ]

Le 26/06/2015 16:01, Douglas Little a écrit :
Actually this whole thing still bothers me at some level. I can't quite
put my finger on it, but something doesn't add up in my head :-)

If there is one big table that specifies cycle counts for CPU
instructions (which seems fair) and everything is relative to that as a
master reference  then surely all other divergences would just cancel
out? Except for divergence vs wallclock time - but that's not an issue here.

i.e. if the DSP runs an op which it thinks takes 2 master cycles and the
CPU runs an op which it thinks takes 8 master cycles, then you can
expect 4 DSP ops executed in that same time.

If something breaks the CPU op timing so it takes 16 cycles, the DSP
just gets to execute 8 ops instead. The CPU got virtually slower. The
DSP did not get faster.

 From the MFP's perspective, the CPU got slower also. So MFP events
happen more often relative to that one CPU instruction. i.e. the MFP and
DSP both agree that the CPU got slower.

So it doesn't seem to matter that everything hangs off the CPU timing
table. What matters is that they all agree on the CPU timings. This is
where something is going amiss - they don't seem to agree.

Does that make sense?



back on this, if we consider a VBL takes 160000 cycles and a move should take 16 cycles if correctly measured ,then we can run 10000 move during 1 VBL and during the same time we have 320000 cycles for the DSP.

Now, if the 'move' is not correct, and takes 32 cycles in Hatari, you still have 160000 cycles per VBL and 320000 cycles for the DSP, but you can only execute 5000 'move'.
So the DSP now looks twice faster than before.

Same for the MFP, from a CPU point of view, if the instruction is ran twice too slow, then the MFP will appear to run twice too fast.

All in all, depending on the mix of under/over estimation of the 68030 instructions, the DSP could appear to run 50 or 70 % faster.

Same goes for HBL interrupt, if some instructions are not correct, they won't happen every 512 cycles in 68000 STF mode.

So, incorrect cpu cycles will really mess with all timings and other external component that rely on the CPU to compute their "frequency".


Mail converted by MHonArc 2.6.19+