Re: [hatari-devel] DSP performance

Hi, thanks for the reply.

If the cycles at cpu side are underestimated, you will get more instructions per second and more DSP speed. At the moment, we can't do much about this :(

But the benchmarks you sent some days ago is the kind of things that can help fixing this. The more cpu instructions we get correct, the better the DSP will run.

This is still a bit curious for me because as I understand things, the mechanism for DSP has not changed between Hatari 1.7 ... Hatari 1.9. (?) so results would have been sensitive to this before as well.

The timings of the CPU instructions have changed a bit - but they were never quite right to begin with. My own benchmarks showed quite large differences in CPU timings for earlier Hatari's e.g. NOP was always 4 cycles vs 2 and didn't seem to matter if executing from the cache (NOP isn't a great example but most instructions I looked at seemed to have some sort of differences, especially memory and host port transfer times, both being relevant here).

The thing is, DSPBench used to report perfect timings from Hatari (it is based a on TimerC counter). Now I'm not sure if somebody 'arranged' that or if it was just spectacular luck that it did that - but it seems a bit suspicous to me that it would leap from perfect results to 70% off, when the CPU cycles were not quite right either before or after 1.9. It seems like something else is going on here, other than CPU cycles?

Anyway I'll leave that thought with you. If it makes sense, then fine. If it seems suspicious, might be worth a closer look sometime.