[hatari-devel] Profiling Hatari code with Valgrind

[David Savinkoff]

Hi,

I've been playing with Falcon emulation and using 'top' on my slow
system P3 1GHz. My opinion is that the dsp has been optimized so
good that there are diminishing returns in optimizing it further.
The problem is more in the rest of the falcon emulation. For example,
when I run Fractal Flight with the dsp I get my system max'd, then
when I switch the dsp to off or dummy my system is still max'd but
the fractal flight continues at the same slow speed until there is no
data for the screen. Removing the dsp effectively makes no speed
difference!

One other whacky bug I get with hatari is sometimes a key is repeating
at boot time. I've noticed that when this happens while booting the falcon,
the emulation gets severely loaded, and stays that way (not a dsp issue).

David

On Jan 6, 2011, Laurent Sallafranque <laurent.sallafranque at free.fr> wrote: 
>
> Hi,
>
> I don't agree with you here.
>
> Update_e_u_n_z is called for nearly every other instruction in the DSP 
> (each instructions that are decoded in the else of the main DSP 
> instruction decoder).
>
> This mean mac, mpy, add, sub, test, cmp, ...
> Nearly all DSP programs use these instructions a lot (and use them 
> millions of time).
>
> I've done a quick Vallgrind tonight to see the difference before this 
> update and after it.
> The difference is not negligeable (compared to the png you sent last time).
>
> I'm running a vallgrind of hatari without this optimization. I'll send 
> you the 2 pngs tonight.
>
> I'm sure I can't see the difference on my fast computer (I never go up 
> to 92 % cpu), but for a slower machine, these small optimizations can do 
> the difference (that's my point of view).
>
> Best regards,
>
> Laurent
>


Le 05/01/2011 21:47, Eero Tamminen a écrit :
> Hi,
>
> On tiistai 04 tammikuu 2011, Laurent Sallafranque wrote:
>> I've given a closer look at the 2 valgring png's that Eero sent us
>> (30lcoke and wildfire).
>> I've seen that dsp_update_e_u_n_z() is one of the most often called
>> functions.
>> (nearly every other DSP instruction). If you cumulate all the calls, it
>> takes a certain time.
> Those programs were very simple 4kB ones so that bottleneck isn't
> necessarily the worst or common one DSP has...
>
> I think it would be best first to collect list of programs which make Hatari
> to use most CPU (or e.g. skip most frames if CPU is at max) and profile
> those to see whether there are common bottlenecks.
>
> Has anybody noticed some DSP utilizing Falcon programs to tax Hatari
> more than other such programs?
>
>
> The Julia fractal part in the beginning of wildfire.prg is pretty bad, it
> uses 90% of CPU even on my new computer and causes autoframeskip of 2
> even when I have sound disabled and use "-z 1" option to minimize screen
> redraws.
>
>
>> I've given it a full rewrite. Can somebody test it and see if this
>> increases speed again ?
> Not really noticeably for these two demos.  I think the larger CPU usage
> spike at the end of Julia fractal in wildfire.prg isn't as bad as earlier,
> but otherwise it seems to be<1% difference.
>
> (I think branches are more expensive than simple calculation operations,
> than may explain why it didn't help noticeably.)
>
>
> Best would be if you use a memory snapshot and the Hatari timing
> functionality (--run-vbls option + very large frameskip with fast-forward)
> for checking speedup.
>
>
>> I wish all these updates accelerates DSP a little for slower computers.
>
> 	- Eero