Re: [hatari-devel] Issues with cache hits/misses?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

(Sorry for late reply, my ISP SMTP server didn't work yesterday)

On maanantai 01 kesäkuu 2015, Nicolas Pomarède wrote:
> Le 30/05/2015 21:35, Eero Tamminen a écrit :
> > What GEMDOS HD emulation should do in presence of data cache, when
> > it modifies emulated memory (e.g. DTA) according to the requested
> > OS call?
> 
> it seems my tests were too quick :) This is fixed, data cache should be
> flushed when HD emulation (or any other part) directly writes to memory.

Thanks, your DTA fix is enough, I can add similar call to
other GEMDOS sites that write directly to memory (listing
files in TOS desktop works, but running programs doesn't yet).

There may also be other places where that needs to be done,
e.g. with debugger command to read file contents into memory...


> > I profiled Hatari and compared how much DSP emulation cost changes
> > in relation to m68k emulation cost.  Based on that I calculated that
> > the 030 cache handling added 10-20% overhead (closer to 10%).
> > 
> > More interestingly, EmuTOS and TOS v3 seems to work at OK speed.
> > 
> > It's only TOS v4 that is really slow.  Either TOS v4 breaks with
> > data cache, or Hatari emulation (VBL timing?) doesn't work with
> > TOS v4.
> 
> I don't know yet, but we can clearly see that even during the early
> memory tests at boot in falcon mode, the screen refresh is very slow (we
> see red and yellow Atari logo, because all 4 planes are not copied fast
> enough to get the 'black' color in one go).

If the emulation itself would just be slow, things would
update slowly, but you wouldn't see intermediate results
(Hatari Videl emu refreshes screen only at every VBL).

Another place where you see intermediate results with TOS v4,
is drawing of desktop menus.  It seems like VBL is triggered
more frequently than it should (after every letter output to
screen?).


> So, this looks more like a 10 times slowdown than just a 10-20% overhead.

10-20% is the host CPU overhead I estimated to come from
cache handling (based on DSP & CPU emulation host CPU usage
ratio).  

And if you test TOS v3 and EmuTOS, they aren't noticeably
slower with data cache.

I.e. Hatari host CPU usage cannot explain why TOS v4 behavior
is so much slower (I think it's more than 10x for menus).


> I will have a look at this, I want to make more tests before
> with the data cache.

To track what happens between VBLs, use:
	profile on 
	b VBL ! VBL
	c
	profile save vbl-profile.txt

From the saved file it's easy to see what happens and where
looping happens.


	- Eero