Re: [hatari-devel] DSP performance

Hi!

My understanding of douglas' mail was that after I updated to more recent WinUAE, DSP speed was still correct, but that it was not correct anymore now. Only changes that could affect cycles lately were to enable data caching

I think I have misled slightly here so I should clarify - I only measured this recently (last couple of days), it may have begun much earlier. I'm not yet sure exactly when it started but I guess it was probably related to the integration of the new core.

(I first noticed Hatari getting a bit faster late around v1.8, I think just after the new core was introduced but please don't rely on that, it is very subjective).

The one thing I'm certain of is that DSPBENCH reported correct DSP timings in all earlier versions of Hatari up to early/mid v1.8, no matter what the CPU cycle accuracy looked like, because I don't believe the cycle accuracy actually matters for this measurement.

There are aspects of course which do matter - but not the cycle counts themselves. More how they are 'agreed' or arbitrated between different pieces of the emulator.

There was one exception - in a much earlier Hatari release (around 1.6) DSPBENCH did report some funny figures but it was due to genuine DSP cycle count errors, and the size of the error related to the fault in that DSP memory operation. IIRC this was fixed in the DSP emulation - not on the CPU side (Laurent can correct me here as I didn't study the changes).

In the modifications he made before, Laurent added some case to compute head/tail cycles, but even with this, cycle counting remains complex, depending on different EA and so on. Some case weres better before and some were worde, now some other cases could be better, but some other could also be less accurate.
There's no perfect solution at the moment.

I agree with all of that - however I don't think the absolute CPU figures themselves matter (from a table or calculated) so much as how they are arbitrated across the different parts of emulation.

i.e. if the DSP sees 4 CPU cycles pass where the MFP sees 8 pass for the same CPU op, then there is a problem. But the actual value '4' or '8' is irrelevant. The timings could be wildly inaccurate for that CPU but so long as the MFP + DSP agree on the numbers, then the DSP will report 'correct time' when measured via the MFP. Only the CPU will appear to change speed.

More specifically, if you happen to double all the figures in the CPU cycle table (or how it gets calculated) the DSP test should still report the same time vs MFP, if the two devices still agree on cycles.

So I suspect the real problem is that different parts of Hatari are obtaining CPU cycles in *different* ways - or obtaining them in the same way, but at different times (e.g. when the figures are not matured/fully calculated for a given operation). This is guesswork on my part and should be treated with caution - but I can't make sense of it any other way.