[hatari-devel] measuring Hatari performance (was: Very big DSP optimisations)
npomarede at corp.free.fr
npomarede at corp.free.fr
Fri Apr 24 00:11:49 CEST 2009
On Fri, 24 Apr 2009, Eero Tamminen wrote:
> On Friday 17 April 2009, Eero Tamminen wrote:
>> So... I have been thinking that Hatari should have some performance
>> Thomas, maybe when the HATARI_TRACE define is set, Hatari could could
>> show a count of how many frames it has displayed and e.g. output a
>> running average of that at certain interval + number of shown frames e.g.
>> on SIGUSR1.
> I though that it could be done a bit more simple, see the attachment.
> The code is so simple that I think it could be included into Hatari as
> Use like this:
> * Start Hatari so that it works as fast as it can:
> hatari --fast-forward yes
> * Press Pause or F12, or invoke them in some automated way:
> sudo apt-get install xautomation
> xte 'sleep 10' 'key Pause'
> (after unpause, counter starts again from zero)
> So, to measure whether some e.g. DSP optimization made things faster, one
> could have a dir which has in auto/-folder a test program that starts
> automatically and then some script could start Hatari with that and after
> some fixed interval simulate a Pause key press. If the FPS increased, the
> optimization is improvement.
> NOTE: For short time periods the FPS value seems to fluctuate quite a lot,
> Hatari needs to run several tens of seconds for FPS to keep fairly stable
> (with few percentages). Hatari speed depends also a lot on what options are
> used (frame skip, spec512, zooming, sound etc), so they need to be kept
> same. And of course there shouldn't be any background activity in the
> meanwhile (better is to run the test multiple times until it stabilizes)
> and one should measure only one optimization at the time.
this is similar to something I proposed some times ago to measure the
impact of some modifications regarding screen rendering (and it similar to
some pc games that run a predefined sequence for 30 sec to see how fast
your PC is), but it has some drawbacks under multitasking OS (linux or
- any running program will interfere with hatari, so you need to be sure
you close all other apps.
- sound can be a problem and can generate latency ; hatari should be run
with sound off.
Nevertheless, this could give some first results on whether a modification
has some impact ; but if the modif only change cpu ressources a few %, it
will be hard to measure because this method has a rather big error margin.
But one could imagine an option 'run for x VBLs then exit'. This way,
you could restore a memory snapshot of the same demo sequence for example,
run it full speed for 30*50 VBLs then exit and measure the time it took.
Perhaps we could also disable video output in that case, to be sure that
no sound/video layer is slowing down hatari and that we're measuring only
hatari's routines (this means rendering the st/falcon screen in memory,
but not sending it to the user's display).
But the most precise way would certainly be to put some "probes" at
specific location when entering/exiting various functions and sum the
More information about the hatari-devel