[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