Hatari emulated speed different on different computers?

[Zamuel_a]

I made a 3D test for Falcon that I have so far only tested under Hatari, but wonder how to setup Hatari to be as accurate as possible to a real Falcon. I have enabled all CPU functions and everything else I can find. The "problem" is that when I tries it on different PCs I get very different results. I have an FPS counter that just measure the 200Hz timer ticks and compares that with the number of frames drawn. On one PC I get something like 8 FPS, on another 18fps and I can visually see it is faster. One machine is slower so I don't expect it to run Hatari as good as the faster machine, but should that affect the 200Hz timer and other things in the emulation?

I guess I need to dig up the real Falcon soon and see which is most accurate.

[troed]

Falcon emulation is not accurate enough to be used for actual speed measurements.

[Eero Tamminen]

I made a 3D test for Falcon that I have so far only tested under Hatari, but wonder how to setup Hatari to be as accurate as possible to a real Falcon. I have enabled all CPU functions and everything else I can find. The "problem" is that when I tries it on different PCs I get very different results. I have an FPS counter that just measure the 200Hz timer ticks and compares that with the number of frames drawn. On one PC I get something like 8 FPS, on another 18fps and I can visually see it is faster.

That's over 2x speed difference...

One machine is slower so I don't expect it to run Hatari as good as the faster machine, but should that affect the 200Hz timer and other things in the emulation?

There may be a measurable difference, but it should not be significant (couple of percent diff, not 2x), if you're using the same Hatari version on both machines, configured (at build time) to use same CPU core, and to use same Hatari settings (at run time).

Except for Falcon RTC that is, as real time clock emulation takes the clock from host... Are you by any chance using anything derived from RTC in your calculations?

(If yes, then accuracy is up to whether your machine is fast enough to emulate things at full speed constantly, and how accurate your host clock is.)

Falcon emulation is not accurate enough to be used for actual speed measurements.

It's definitely good enough for performance analysis: https://hatari.tuxfamily.org/doc/debugg ... #Profiling

(Best example of latter is BadMood development documented in its own thread here.)

And it should be good enough to get some rough speed estimate. It helps to know how accurate specific things are though: https://hatari.tuxfamily.org/doc/debugg ... a_accuracy

[Zamuel_a]

I use the same version (2.3.1) and same settings, but I did see one difference that seems to solve it. I hadn't enabled the MMU on my slower PC since it makes the emulation very slow. I tried with it on and now I got almost the same FPS as on the other machine, but everything goes slower so it looks worse but the FPS is higher.
I didn't think the MMU would make such a big difference.

[Eero Tamminen]

I use the same version (2.3.1) and same settings, but I did see one difference that seems to solve it. I hadn't enabled the MMU on my slower PC since it makes the emulation very slow. I tried with it on and now I got almost the same FPS as on the other machine, but everything goes slower so it looks worse but the FPS is higher.
I didn't think the MMU would make such a big difference.

I do not see either how MMU would make such an impact unless caches would be disabled when there's no MMU. I guess you are not using any external code that would rely on MMU presence for it to properly set up caching?

I know that EmuTOS and TOS v4 set up MMU somewhat differently. When MMU is enabled, is there a speed difference in your test program between them?

PS. Looking at Hatari docs, I noticed this:

Code: Select all

HW registers region is not cacheable for 68030 without MMU when write allocate mode is enabled

I assume "HW registers region" means IO addresses, and "write allocate mode" is the caching bit that:

...eliminates stale data that may reside in the cache because of either ... multiple mapping of two or more logical addresses to one physical
address within the same task, or allowing the same physical location to be accessed by both supervisor and user mode cycles.

Which does not seem relevant for your benchmark, only when doing multitasking(?).

[Zamuel_a]

I use a real TOS version on both machines and not any multitasking or anything. If I disable more of the CPU functions (to make the simulator faster) the FPS drops to 1-2. So the settings affect a lot.

[Zamuel_a]

I tried my program on a real Falcon and it runs in 3-5 fps (sadly) instead of the 8 or 18 I get on different PC machines. A fast PC with all CPU stuff enabled runs at 18fps and the more stuff I remove from the emulation, the slower it gets, but not nearly as slow as on the real machine.

[Zamuel_a]

I tried on the real Falcon to turn on/off the cache with the program Falcon SX, just to make sure the cache is on and with it OFF I got 1 fps and ON 4, so the cache must be on. Very strange why the program runs at up to 20fps on a fast PC with all CPU emulation options on.

[Eero Tamminen]

I tried on the real Falcon to turn on/off the cache with the program Falcon SX, just to make sure the cache is on and with it OFF I got 1 fps and ON 4, so the cache must be on. Very strange why the program runs at up to 20fps on a fast PC with all CPU emulation options on.

Could you build your program with symbols, enable profiling ("profile on") at start of your 3D test, save the resulting profile data ("profile save profile.txt") at end of the test, and attach that here?

(To make sure that no extra stuff is in profile, you could either set breakpoints at start and end of the test program, or add debugger invocation NatFeats call to your code.)

[Badwolf]

I don't think Hatari correctly emulates memory access speed, at least under Falcon/030 mode.

With all the stock Falcon compatible emulation settings turned on in Hatari (so 16MHz 030, ST-RAM only, TOS4 etc.) on a modest host machine my Frontier Intro frame counter benchmark clocks broadly the same as my 50MHz Falcon with 100ns AltRAM.

NEMBench is very confusing, for example:

hatari-quick.png

BW

[Rustynutt]

I know that EmuTOS and TOS v4 set up MMU somewhat differently. When MMU is enabled, is there a speed difference in your test program between them?

Interesting, for an Afterburner 040 prospective.

[Zamuel_a]

Now Hatari is even more confusing Without changing anything from yesterday, now when I exit my program and goes back to Pure C everything is very slow. Takes like 10 seconds to redraw the screen, bitplane by bitplane. When I start my program it goes fast but GEM is increadible slow. When I remove my code to set the cache register, my program now runs at 3-4 fps, more similar to a real machine and GEM is fast after exit.

[Zamuel_a]

I figured out that if I touch the cache register, CACR, when Hatari is "messed up" and is way to fast. On my real Falcon I get 1-2 fps with cache disabled and 4 with cache on. I have tried different settings. Data cache on/off and so, but it just get slower than keeping the default settings and not touch the cache at all.
In Hatari, if I touch the cache register and enable instruction cache (even that it should already be enabled as default), when I get 18fps on my faster PC machine and halv that speed on a slower.

[Eero Tamminen]

In Hatari, if I touch the cache register and enable instruction cache (even that it should already be enabled as default), when I get 18fps on my faster PC machine and halv that speed on a slower.

Could you provide a minimal program demonstrating this issue, so that others could also debug it?