[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:

> Hi,
> On Friday 17 April 2009, Eero Tamminen wrote:
>> So... I have been thinking that Hatari should have some performance
>> metrics.
>> 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
> is...?
> 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 
others) :

  - 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 
total time.


More information about the hatari-devel mailing list