Re: [hatari-devel] Hatari WinUAE speed comparisons with Falcon030 / 16MHz

[Douglas Little <doug694@xxxxxxxxxxxxxx>]

BTW my 'reading' of the fractional cycle results is that the bus doesn't yield to the CPU synchronously, but causes waitstates at some non-integral of the CPU speed. Even if the bus is yielding at 16MHz it might be skipping slots and the average results in a fraction. The pattern can probably be worked out from the results, although I'm not sure of that yet.

D

On 19 September 2014 18:32, Mariusz Buras <mariusz.buras@xxxxxxxxx> wrote:

A trivial question, but are you disabling interrupts for the duration of your test?

Regards,

Mariusz.

--
Cheers,
Mariusz Buras.
---
http://sqward.net

On 19 September 2014 18:28, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

While working on a profiler tool, I captured some performance differences between Hatari and a real Falcon.

The profile captures differences on just two instructions - a trivial ALU instruction (add.l Dn,Dn) and a word move (read) operation. The same tests are repeated with different permutations of I/D caches - and PMMU is used to inhibit caching for some tests via custom page descriptors.

The VIDEL was deliberately shut off to limit bus contention on the F30 while the tests were running, to get memory profile results as close to ideal as possible.

The results are quite varied. It is probably most interesting that the F30 results indicate single operations using fractions of a cycle for *anything* involving memory accesses - while pure cached operations round exactly to 16MHz cycles as expected. This is despite the VIDEL bus fetching being disabled. That one is going to be fun to figure out :) 

Hatari/WinUAE:

https://dl.dropboxusercontent.com/u/12947585/grab0010.jpg

F030:

https://dl.dropboxusercontent.com/u/12947585/prf.JPG

The profiler tests are still very limited but I'll be adding interesting cases as time goes on, particularly around different addressing modes, overlapping fetches, head/tail cycle cases and so on.

D