[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