Re: [hatari-devel] Hatari data cache tests

Here is an interim version which should at least provide some info while I fill out the rest...

https://dl.dropboxusercontent.com/u/12947585/nb030_v100.zip

Invoke with -f030 for Falcon tests in the desktop video mode. Additionally pass -videl to shut down video fetching during the tests for a better baseline (expect a black screen for an extended period!).

It will write a nb.log file which can be extracted from a real machine to compare with Hatari. All tests are cycle-accurate. Non-integer cycle timings are side effects from various things - mainly the bus.

I'll post another version with more tests if it proves useful.

On 18 June 2015 at 19:47, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

Le 18/06/2015 18:19, Douglas Little a écrit :

I did get some warnings like this during recording, which I haven't
investigated yet....

ERROR: trying to add costs to non-existing 0x1012480 caller of 0x10114e8!
ERROR: trying to add costs to non-existing 0x101242c caller of 0x10114e8!
ERROR: trying to add costs to non-existing 0x1012480 caller of 0x10114e8!
ERROR: trying to add costs to non-existing 0x101242c caller of 0x10114e8!
ERROR: trying to add costs to non-existing 0x1012480 caller of 0x10114e8!

I also noticed that trying to profile code with TT ram allocated doesn't
work very well as it slows my test down to less than 1fps, and can halt
for several seconds at a time. While it's probably reasonable that it
could get slower as the memory footprint increases, it seems to be
happening in a very nonlinear way and the actual amount of code being
executed remains the same. The code is executing from TT ram at the
time, so perhaps that has something to do with it.

Hi

The error message is related to the profiler, and the slow down you noticed might also be due to the profiler collecting some stats in a linear way maybe (instead of using dichotomy or sthg similar to search a huge list).
Eero will certainly know better how this works.

I'll see what else I can find....

Just in case you're bored or want to take a break from quake :) maybe you could write some kind of small benchmark that would count how many instructions (simple read or write, byte, long, ...) can be executed before a predefined MFP timer expires. This would allow to precisely measure the difference between emulation and real HW (I agree I could also write this program myself and send it to falcon owners, but I didn't have time recently :) )

Nicolas