|Re: [hatari-devel] DSP performance|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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?
Yes, that make sense and could be possible, but it's hard to be
affirmative without a specific piece of code that could be ran in disasm
mode with all timing next to each cpu/dsp instructions.
I can also see example where some instructions coud be much too slow or
much too fast, and then I'm not sure the average DSP speed would be