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.