[hatari-devel] Timer-D CPU usage in latest Hatari

Eero Tamminen eerot at users.berlios.de
Sun Jul 12 20:35:10 CEST 2009


Hi,

On Saturday 11 July 2009, Thomas Huth wrote:
> 2) What about Spectrum 512 screens? Could you please test how much CPU 
> time this (old) renderer currently takes on your system (e.g. the "Clown
> screen" in the menu of Automation 136)?

The Clown screen takes ~53% CPU for me[1].

I took some rough measures from other demos
(with "--zoom 1 --borders on --frameskips 0"):
- CareBears SoWatt menu: ~48% CPU usage
- 1984 NoCooper demo SoZatt menu: ~55% CPU usage
  - the "colorshock" screen in this demo managed to take: ~70% CPU

When I zoomed the last screen, the *ST* emulation actually took all of CPU
with the X server CPU usage (automatic frameskip kicked in).  I had no clue
Hatari's ST emulation could take all CPU (on my 1.4Ghz machine)[2].

As a comparison, CheckPoint's SureTrip demo causes Hatari to take only
~25% of CPU usage for first screens.


[1]: Using the "Patch Timer-D" option nearly halves the Clown screen CPU
usage to ~29% and nearly reduces the "colorshock" screen CPU usage to
1/3 (to ~28%).  SureTrip goes to 5-20%.  This is because without this
optimization in these cases by far most of the time is spent in handling
the MFP Timer-D interrupts. According to Valgrind/Callgrind/Kcachegrind
1/2 CPU goes to MFP Timer-D, 1/3 to sound handling (mainly SDL_mixer
thread + ALSA), 1/6 to m68k emulation and Spec512 conversion/palette
routines etc.

[2]: I hadn't noticed the significance of this earlier because I've earlier 
run Hatari always with the Timer-D patched.  More importantly, it seems to
have an effect only if it's done at bootup (I guess only TOS sets
the frequency, at least in these cases I tested).  I.e. if one toggles
it at run-time from the GUI, there's *no* difference which can mislead
people.

The most amazing effect of Timer-D is on idle (TOS 1.4) GEM desktop.
Without patched Timer-D, current Hatari takes 40% CPU, with patched Timer-D
it takes 1-3% CPU (and occasionally 20%, Hatari v1.0 takes 20% constantly).


Currently Timer-D patching can be controlled only from the GUI & config
file.  Because of [1] & [2], I think there should be a commandline option
for it too, maybe:
  --patch-timerd <boolean>  Enable for much improved performance

It's performance impact should also be highlighted better in the manual.
Maybe I should add an "How to speed up Hatari performance" section
to the manual (e.g. the www-site FAQ doesn't mention Timer-D at all)?  


	- Eero



More information about the hatari-devel mailing list