[hatari-devel] DSP optimization?

Eero Tamminen oak at helsinkinet.fi
Sat Jan 15 16:07:43 CET 2011


Hi,

On lauantai 15 tammikuu 2011, Nicolas Pomarède wrote:
>> Now that Hatari DSP code doesn't anymore track Aranym, could we change
>> the dsp_core to be a static array like CPU core data is?
>> 
>> Accessing the core through a pointer is a small overhead in about
>> everything DSP does and we don't gain anything from it as Hatari will
>> never emulate more than one DSP at the time (like AFAIK has been the
>> idea with the Aranym DSP code).
> 
> on contrary to what it may look, it's not obvious that such patch would
> make things faster.
> 
> For example on 680xx cpu, "address register indirect with displacement"
> is faster than "absolute long", which means "move.l 12(a5),d0" is faster
> than "move.l $75120,d0".
> 
> I don't know for recent cpu (x86, arm or others), but it's also possible
> you get similar results (harder to measure with moderm
> pipeline/reordering).
> 
> It would need to be profiled to see if there's a real different between
> dereferencing a pointer or accessing directly the memory address, but I
> don't think the gain would be noticable on CPU that would benefit from
> it, and it could even be negative on 680x0 cpu or others cpu.

Attached are modified dsp*.[ch] files for anybody who wants to test.

(Diff to them is almost as large the files.)


	- Eero

Because I have multiple cores which are frequency scaled, it's not so
easy for me to see the difference.  I'm not sure whether even this
(as root of course):
---
for cpu in /sys/devices/system/cpu/*/cpufreq/scaling_governor; do
	echo "performance" > $cpu;
done
---
Would guarantee enough things?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dsp.tar.gz
Type: application/x-compressed-tar
Size: 41276 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20110115/19af9bf5/attachment.bin>


More information about the hatari-devel mailing list