Re: [hatari-devel] DSP performance

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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?
>
> D

Hi

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".

Nicolas