FS-UAE v3.1 - fastest possible configuration slower than WinUAE?

[PeterK]

Hi Frode,

I'm trying to set up the fastest possible FS-UAE configuration, but couldn't find out how to get it. My PC has a Celeron N4100 4x1,1 GHz (up to 4x2.3).

I don't want to emulate a particular Amiga model, just the fastest possible what I can get out of my PC. But whatever setting I've tried so far, WinUAE is 10-30 times faster. So what am I doing wrong in the FS-UAE setup or configuration? Where is the magic switch to get full speed? One example config:

# FS-UAE configuration saved by FS-UAE Launcher
# Last saved: 2021-11-08 20:38:53

[fs-uae]
accuracy = -1
amiga_model = A4000
cdrom_drive_count = 1
chip_memory = 2048
cpu = 68060-NOMMU
cpu_idle = 0
floppy_drive_count = 2
floppy_drive_speed = 0
graphics_card = uaegfx-z3
graphics_memory = 32768
hard_drive_0 = E:/OS39
hard_drive_1 = D:/UFOs
jit_compiler = 1
jit_memory = direct
kickstart_file = kick40068.A4000.rom
uae_chipset = aga
uae_chipset_compatible = generic
uae_cpu_speed = max
zorro_iii_memory = 131072

Update:
In fs-uae.log I found the following entries although I explicitly set "accurary = -1" and also "accuracy = Low" in the GUI:

configuring "Amiga 4000", accuracy=1
amiga_quickstart model=6 config=0 compa=0 (accuracy 1)

The other main difference compared to WinUAE is the usage of OpenGL instead of DirectDraw or Direct3D, but even the pure CPU performance is still much lower.

[PeterK]

Seems that somebody has moved my post out of the FS-UAE 3.1 thread and into this new thread ... OK, just couldn't find my old post at the first moment

Frode, I could improve the speed a lot now by adding the option "uae_cpu_throttle = 5000", although the docs say that it should have no effect in fastest-possible mode:

In fastest-possible mode, you can only use this option to slow down the emulation (-900.0 - 0).

At the moment I cannot get full speed, because my PC is connected to the internet with other Windows applications running in the background, but FS-UAE is already about 10 times faster now.

I still don't understand how I can get rid of the "quickstart" and the "cycle_exact" mode. The "accuracy = -1" seems to be ignored. In WinUAE I can choose a "High-end expanded" configuration, but I don't know how to get this in FS-UAE.

My "Movem.w_test" is working correctly now on 3.1 and at the first glance everything else looks good, too. Thanks a lot for this update!

[FrodeSolheim]

Hi, I moved your post and I *was* going to tell your about it

I moved your post to a separate thread because I suspected there could be some follow-up posts and possibly investigation going on for this one.

There is some overlap with this thread: https://eab.abime.net/showthread.php?t=108444, so can you see if some of those replies apply. In that thread, a couple of particular AIBB tests were slower than on WinUAE, and this was found do be due to uae_immediate_blits=true being enabled in WinUAE by default, but not in FS-UAE.

Regarding the "accuracy quickstart"; FS-UAE uses the a single quickstart mode from WinUAE but overrides some of those options afterwards with accuracy is lowered. You can see this in your log:

set option "cpu_speed" to "max" (result: 1)
set option "blitter_cycle_exact" to "false" (result: 1)
set option "cpu_compatible" to "false" (result: 1)
set option "cpu_cycle_exact" to "false" (result: 1)
set option "waiting_blits" to "false" (result: 1)
set option "immediate_blits" to "true" (result: 1)

Another possibility; I know that the fastest-possible mode isn't very well implemented in FS-UAE 3. I know this because I spent a lot of time understanding "fastest possible mode" code better for FS-UAE 4 and I rewrote most, if not all of the FS-UAE timing code related to that. It is possible that in FS-UAE 3, the emulated CPU isn't getting enough cycles, reliably.

Let's try to find out... -Are you interested in trying to boot the system with the latest FS-UAE 4 build and seeing if it runs significantly faster?

[PeterK]

Yeah, I saw that other thread already, but then he said:

Thank you! The "accuracy=-1" parameter solved it (the "uae_immediate_blits=true" did not).

... that's why I tried it with accurary=-1, but "uae_cpu_throttle = 5000" was the missing magic option in my configs. I will report exact speed results as soon as I can do more reliable benchmarks without other apps running in the background.

Yes, I would like to test FS-UAE 4, because WinUAE is getting a little slower now in the latest 4.9 beta compared to 4.4, and I prefer to have fast emulations on my low-end Mini-PC.

[PeterK]

I've done some benchmarks with FS-UAE 3.1 and now I can get the same "fastest possible" speed as with WinUAE in most cases when I use the following options:

accuracy = -1
amiga_model = A4000/040
chip_memory = 2048
cpu = 68040-NOMMU
cpu_idle = 0
graphics_card = uaegfx-z3
graphics_memory = 32768
jit_compiler = 1
jit_memory = direct
kickstart_file = kick40068.A4000.rom
uae_cpu_speed = max
uae_cpu_throttle = 30000
zorro_iii_memory = 131072

With values higher than 30000 for uae_cpu_throttle the system starts reacting abnormal, the clocks are running too slow, the mouse pointer has lags, and you will get higher but wrong benchmark results, because time sometimes stands still. The limit for uae_cpu_throttle may also depend on the used hardware, this is just a value which works on my PC.

Independent from these throttle settings, the icon benchmark "OpenWin.rexx" did freeze a few times in FS-UAE, most often with a 060 CPU. The emulated system was still reacting, but the icon rendering stopped. I've to do more investigations why this happens.

[FrodeSolheim]

Great Could you try removing one and one option to see what options does not matter? For example,

uae_cpu_speed = max

should have no effect - it's already set by FS-UAE for this model. Similarly,

jit_memory = direct

should also be default for the jit compiler.

[PeterK]

Yes, I can check out which options are really required in addition to the defaults.

Btw, why was the limit for uae_cpu_throttle in your documentation 5000 ? I don't know yet whether there could be some other hidden side effects with higher values than 5000 already. That needs a lot more testing within the next days ...

[jbl007]

Are you sure that cpu_speed=max is correctly applied in your config? Check debug.uae in the Logs directory. If so, then cpu_throttle can only be negative. Because you can't go higher than max. That's not how the universe works. At least not our universe.
For me it looks like you are on "real" speed and that's why a pos. val. has an effect...

Originally Posted by PeterK

Btw, why was the limit for uae_cpu_throttle in your documentation 5000 ?

I'm pretty sure this comes from the WinUAE GUI. Max val. here is +500% which translates to cpu_throttle=5000.0 I checked the source code (which I totally do not understand ) I didn't find a limit. (However the seem to be a limit for the CE multiplier (255)).

For better debugging you should start with a much more simplified config:

accuracy = -1
amiga_model = A4000/040
graphics_card = uaegfx-z3
zorro_iii_memory = 131072
jit_compiler = 1

[PeterK]

@jbl007
In my post #2 you can see that I also was surprised that setting a positive value for "uae_cpu_throttle" could improve the speed (a lot), although "uae_cpu_speed=max" was already activated in all my configs. And indeed, both options are appearing in debug.uae too:

cpu_speed=max
cpu_throttle=30000.0
cpu_type=68040

So, either the docs are wrong, or FS-UAE works differently than explained there, maybe also different to the way WinUAE works.

But I won't care about the rules of the universe as long as it works for me, and it's really 10-30 times faster with this option now.

@Frode
For the 68020 I need the options:

cpu_idle = 0
uae_cpu_speed = max
uae_cpu_throttle = 30000
uae_fpu_model = 68882

For the 68030:

cpu_idle = 0
uae_cpu_throttle = 30000
uae_fpu_model = 68882

For 040 and 060 only:

cpu_idle = 0
uae_cpu_throttle = 30000

and for a Blizzard 1260:

cpu_idle = 0
jit_memory = indirect
uae_cpu_throttle = 30000

... provided that the JIT and "Accuracy=Low" are also enabled in the GUI.

The optimal value for throttle is experimental and may depend on the PC hardware. These 30000 are working perfectly on my system, but I can't test that on other PCs. The optimum is reached when all parts of system are getting enough CPU cycles, you'll have to find the best throttle value for a good balance yourself.

Btw, the freezes of the "OpenWin.rexx" benchmark also occur with the original icon.library v45.1. It's very difficult to debug that, because it happens very rarely, but I've never had these freezes with WinUAE.

[daxb]

Maybe it is a race condition because of that it opens and closes the window as fast as possible (in assumption that it freeze while doing this). You can set the "MyDebug" variable to >=2 to get debug output. This could also help to see when the freeze happens. Although it might bypass a race condition because of slower execution.

[PeterK]

@daxb
Thank you for this hint! I will try that option, too. Yes, sometimes running debugging tools can prevent bugs like these freezes. I already tried Enforcer, but then it did never happen anymore.

My assumption is (just a first guess), that the freezes are caused by the filesystem handler/driver for Windows directory access. I will also copy the system onto a HDF formatted with FFS or PFS to see whether it's coming from the filesystem access.

Oh, I've forgotten that I could run "OpenWin.rexx" easily and much faster from the Ram Disk instead of from the HDD.

[PeterK]

The freezes of the icon loading benchmark "OpenWin.rexx" did not happen when the icons were loaded from the Ram Disk, although that's nearly 4 times faster than from a Windows dir. FS-UAE seems to have a different filesystem handler and device driver for Windows than WinUAE. On the latter I could see the disks in SysInfo as "uaehf.device" entries, but there was nothing on FS-UAE.

Unfortunately, the debug output from the benchmark script doesn't show any error messages. The logging always stops after the Workbench window has been opened and the icon loading has already started and is still in progress, and before the timer is stopped again. Intuition is still reacting, I can click windows to the front or into the background, but the rest of the system is blocked. It looks like a deadlock in the filesystem or device driver.

[FrodeSolheim]

Originally Posted by PeterK

FS-UAE seems to have a different filesystem handler and device driver for Windows than WinUAE. On the latter I could see the disks in SysInfo as "uaehf.device" entries, but there was nothing on FS-UAE.

It really is the same as far as the Amiga is concerned. Only on the host side is the code different between FS-UAE and WinUAE. So it has to be something else. Also, if you want to compare apples to apples, you should try with WinUAE 4.2.1. Either that's the difference here, or some other difference in "effective" configuration is at play here.

Tip: FS-UAE writes a file called debug.uae to Cache/Logs. This represents the "final UAE configuration" after applying Amiga model and override options. So this file is suitable for comparing to a WinUAE config file to see what actual in-use options are different.

[PeterK]

Confirmed, it's not the filesystem. I had a first freeze now with a HDF and PFS3 under OS 3.1.4 on a PAL screen. This time, FS-UAE was also (o.c.) using uaehf.device for the HDF, as WinUAE does it for mounted directories. Atm, I don't know what else the reason could be.

Till now, I had freezes with all CPU types, with JIT or without JIT, with OS 3.9 or OS 3.1.4, with mounted Windows directories or a HDF, with different filesystems, with uaegfx/P96 or PAL, with my icon.library or the OS iconlib, and with or without the throttle option.

I didn't have freezes with the Ram Disk or in non-JIT mode yet. I will try again ... doing more tests, but until now it seems to be a combination of Windows disk-io and the JIT compiler. Is there something in the code where both are involved which could cause a deadlock?

[PeterK]

Update concerning the FS-UAE freezes: it has happened even in non-JIT mode now after many long tests.

Only the benchmark tests on the Ram Disk didn't freeze yet, so it looks like disk-io problem on the Windows side, maybe some buffer protection with a deadlock? I will try to catch it with some Windows tools like FileMon or ProcessActivity.