Re: [hatari-devel] DSP performance

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi all,

Until now, I've always thought that the first fight for Falcon emulation was the accuracy of the CPU cycles, as the cpu is THE clock for all the system.

When I did the static cycles table in the previous version of hatari (until 1.8), I did recompute the whole table for 16 bits memory acces and for .w or .l instructions (cycles are different due to the cycle access).

Maybe the current 68030 cycles are for a 32 bit computer (as the amiga 68020 is) and the cycles are not recomputed for a 16 bits BUS. As the cpu core is issued from winUAE, it may be something like that.
Maybe there's something else to search ;)

I know my static table was not perfect at all, but it seemed to give a not so far timing accuracy from a real falcon.
I spent more than 1 month recomputing the figures according to Mikro's documentation about 68030 cycles in the Falcon.

I don't know where the cycles are computed in the new engine (I should take the time to have a closer look at this).

Regards
Laurent
 

Le 27/06/2015 07:58, Douglas Little a écrit :

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.

D