FS-UAE for productivity Amiga?

[Der Wanderer]

I had a look at FS-UAE on Windows8 and it seems to be pretty good, but it has a few short commings that make it not work for me. (productivity Amiga needed)

1. no JIT?
It seems to not have a JIT, that makes it 50-200 times slower than WinUAE. Also, the CPU performance seems to be very irregular, sometimes it almost freezes.
The graphics operations seem to be very fast though (blitbmap).

2. no UAE audio
Seems the only way to get audio out of it is 14bit Paula. I really need an AHI soundcard with at least 16bit/stereo recording and playback.

3. Cant name the harddrive folders
Ok, this is not a biggie, but it would be nice if you could give them names different from the actual folder name.

4. When using in full screen mode, you cannot easily switch between Windows Desktop and Amiga Desktop.
This is probably a bug, when I go back from Windows Desktop, the Amiga is a small black rectangle on top of the screen. I have to F12+ESC to get a correct Display again.

Any hints if those issues will be addressed in the foreseeable future?

[jbl007]

1. You can use JIT, but not on Windows. Even DMA works if you emulate an 68020.
3. You can relabel your hard drives. See http://fs-uae.net/options#hard_drive_0_label
4. Driver bug? Try another fullscreen mode. http://fs-uae.net/options#fullscreen_mode

[Der Wanderer]

1. Why no JIT under Windows? Should be the easiest since its already there in WinUAE.
It this a political or technical reason?

Still, I think there is something wired going on. The speed varies a lot in maybe 2-4 sec intervals. You can see this e.g. when you watch a mandelbrot rendering. Technically every scanline should be approx. same speed, but some lines are fast, and some very slow, and this is not due to the content that is rendered.

What do you mean by "DMA works"? If I have disc access, it should be DMA since the host system does DMA, or is the emulation task blocked?

2. No ahi driver? I guess it is time to write one... if FS-UAE would provide the same interface to the audio stream, the winuae ahi driver could work. Even though I would prefere a native one that can directly use low latency audio like ASIO.

3. Thanks. Works fine!

4. When I use fullscreen as window it works. Thanks for pointing this out.

Another issue that I noticed:

Is there an interface to native code?
I use that for some performance ciritcal stuff under WinUAE. It works pretty nice if the .DLL you open does not expose data structures, the endianess issue it not problematic.
Some of the OS components could be dramatically improved this way, e.g. text rendering. Just an idea. Maybe I should open a feature request thread?

[FrodeSolheim]

1. See the thread Question about the possibility of JIT in FS-UAE under Windows.

You are probably right that frame rate and performance is somewhat erratic in fastest-possible mode and/or with RTG graphics. It is an area where I do not have a complete understanding of what's going on, and I haven't made enough effort to make it work "perfectly".

2. There is no support for AHI, and it isn't really planned either. That does not mean it won't be implemented (I haven't checked how much work it is). Using the Amiga-side AHI code is a no-brainer, using WinUAE's audio output code is less likely. There may be inter-dependencies with other WinUAE code, and I'm mostly interested in writing code which works for multiple platforms. I currently use OpenAL for audio support. An OpenAL <-> AHI audio bridge isn't off the table...

4. The behavior you describe is not normal. It could be a driver bug as jbl007 suggests... But I see you have already "sorted it out"

FS-UAE does not have anything corresponding to the feature in WinUAE where Amiga-side code can talk to native DLLs. I haven't planned anything in this regard either. It probably is feasible to make something similar to what you suggest here. The question is if anyone will make the effort to implement it...

[Der Wanderer]

1. I see. Would be nice if we get the JIT under Windows too. I think many people are interested in High End Emulation. And FS-UAE is alredy pretty close catching up with WinUAE, with the awesome benefit of running on Linux and Mac too.

2. There are two ways to get AHI on FS UAE:
a) writing an FS UAE driver that directly talks to the host driver
This is more work, but gives optimal performance, maybe a driver for Mac, Linux and Windows is needed seperately.
b) doing it the "WinUAE" way of providing special register addresses that do audio i/o.
Maybe this is even already compiled in. In that case the uaeaudio driver that already exists can be used. Supports only 16bit and default recording device though, but works.

4. It looks like something is wasting a lot of time in a busy loop. Because it can probably run at "full" speed all the time, but it slows down and up in a sin curve. Looks like interference with the VBlank. Probably a lot of unnecessary screen refreshes happen.
Without this fix, RTG is not really usable, at least very unpleasent to use. I would bet that non-RTG is affected too, but the speed when slowed down is still enough for A500 emulation. Still a battery drain on a laptop.

5. Having native support would be awesome for High End users, since some libraries, including some from the OS can be made native and not only accelerate, but also provide functionality that is otherwise not (easily) possible.

++++++++++++++++++++++++
Edit
I have tried FS UAE on a Mac, but still no JIT. :-(

Is there any secret custom option I have to use to get it running?

BTW, I see the same slowdown of the CPU on Mac. So I guess every user has it, not only Windows and not only my machine.

Edit2:
Got JIT running, requires to set uae_cachesize.
Muuuch faster on Mac now, but still much slooower than WinUAE, because of the bug I reported above. Speed alters from fast to 1:100, in an oscillating pattern.

[Der Wanderer]

Let me give you some test results:



This is the speed over time. Every vertical blue line is a second.

I tested on a Lenovo Thinkpad with Intel i7 / 2.5GHz.
Absolute numbers don't really mean anything, this is roughly the time needed for a Fast-Fourier Transformation on a 256p window.
The red dotted line is the average speed.

I measured on WinUAE with and without JIT, and with the very same AmigaOS installation on FS UAE. I closed all programs on Windows side and on AmigaOS side.

What you can see:
1. JIT is obviously much faster
2. WinUAE is much faster than FS UAE, both without JIT
3. FS UAE has wired speed behaviour. Note that the scale is logarithmic, the speed difference between the min and max is huge.

I hope this helps to debug FS UAE. Fixing this would give a huge boost even without JIT.
I will make this benchmark complete by running this stuff on a Macbook Pro.

[jbl007]

The graph looks really strange. I never noticed such huge slowdowns, but I didn't do any benchmarks.
Did you also test without vsync? What happens if you activate warp (F12+w) while benchmarking?
Also "uae_cpu_idle=0" may worth a try. To bad, I don't have much time at the moment for testing. (xmas and stuff... ).

By "DMA" i meant direct memory access from the emulated Amiga to the host system, when using JIT. It is a little faster. It can be enabled by:

uae_comp_trustbyte=direct
uae_comp_trustword=direct
uae_comp_trustnaddr=direct
uae_comp_trustlong=direct    # this one crashes using 68040

[FrodeSolheim]

Originally Posted by Der Wanderer

1. I see. Would be nice if we get the JIT under Windows too. I think many people are interested in High End Emulation. And FS-UAE is alredy pretty close catching up with WinUAE, with the awesome benefit of running on Linux and Mac too.

I may give it a try again soon, it is probably just a little thing which keeps it from working. Of course, figuring out that little thing could take ages ;-)

Originally Posted by Der Wanderer

b) doing it the "WinUAE" way of providing special register addresses that do audio i/o.
Maybe this is even already compiled in. In that case the uaeaudio driver that already exists can be used. Supports only 16bit and default recording device though, but works.

For my part, the only reasonable solution is to take the "Amiga-side device code" from the WinUAE, reuse that but replace the Windows API functions. It is not a priority, but I might look at it after releasing FS-UAE 2.4.x.

Originally Posted by Der Wanderer

...it slows down and up in a sin curve. Looks like interference with the VBlank.

There is basically two problems:

• Fastest-possible mode is done a bit hack-ish (=Make it more or less work, without fully understanding what is going on). A partial rewrite must be done after reviewing and fully understanding the fastest-possible code path.
• RTG refresh is linked to the chipset vsync, even though the RTG device may run independently of the Amiga chipset. This may or may not be a factor here, but the RTG code should probably be partially rewritten to make it work better (after actually trying to understand the corresponding WinUAE code ).

Originally Posted by Der Wanderer

3. FS UAE has wired speed behaviour. Note that the scale is logarithmic, the speed difference between the min and max is huge.

Good thing you mentioned logarithmic, because it didn't look to bad on the graph itself

Originally Posted by Der Wanderer

I hope this helps to debug FS UAE. Fixing this would give a huge boost even without JIT.
I will make this benchmark complete by running this stuff on a Macbook Pro.

Actually, the graph / benchmark looks very useful. Being able to measure and visualize performance over time will surely help debugging and fixing (it'll also be easy to see when it is fixed). Do you have link to (and/or instructions for) the benchmarking program/setup?.

Originally Posted by jbl007

It can be enabled by:

uae_comp_trustbyte=direct
uae_comp_trustword=direct
uae_comp_trustnaddr=direct
uae_comp_trustlong=direct    # this one crashes using 68040

Interesting... this used to crash FS-UAE, which is why the options are by default set to "indirect". I guess it started working when I rewrote the memory manager (mman) a while ago to work more like WinUAE, including allocating a contiguous large virtual memory area (it's a good thing overcommiting memory works on Linux/OS X ). I cannot really say why uae_comp_trustlong does not work like the others.

[Der Wanderer]

Here is the benchmark program. I will experiment with a little more.

If you wonder what the "speed" value means:

This is the milliseconds it took in average to calculate 6 FFTs of order 8, plus a little buffer filling overhead. It should reflect fairly realistic what a CPU intense task would look like. But even more problematic than the average speed is the speed change in FS UAE. As i said, the scale is logarithmic and averaged over a certain interval (6x FFT). This means the CPU almost stalls at the lowest point. That makes anything that does something realtime-ish not work smooth (audio, games, GUI etc.).

You can read from this:

- WinUAE without JIT is about 4x faster than FS UAE without JIT
- WinUAE with JIT is about 50x faster than FS UAE without JIT
- WinUAE with JIT is about 13x faster than WinUAE without JIT

[FrodeSolheim]

Thanks, the benchmark program should come in handy!

Btw, it looks like JIT on Windows will work in the next development version...

[Der Wanderer]

Here is an updated benchmark with MacBookPro.

Sorry for the mess, I don't have much time to make a nicer chart.

You can see that the Mac Version suffers from the very same slowdown problem, so it is very unlikely a driver issue.

Generally sadly, the Mac version is slightly slower, even though it's a brand new MacBook Pro 15". But this is still not really significant compared to the slowdown problem.



The greenisch plots are from Mac.

This is

FS UAE: no JIT ca 20% slower on Mac

FS UAE with JIT is still 7x slower than WinUAE

I guess 95% of being slower is due to the strange cyclic slowdown. The cycle seems to be quite accurately 6 secs consistently on windows and mac. So doesn't seem to be a monitor sync issue either, since the two machines have different monitors.
Can anyone confirm this strange behaviour?

[amigafreak68k]

Originally Posted by Der Wanderer

Edit2:
Got JIT running, requires to set uae_cachesize.
Muuuch faster on Mac now, but still much slooower than WinUAE, because of the bug I reported above. Speed alters from fast to 1:100, in an oscillating pattern.

This could be related to indirect memory access under linuxish systems. On Windows WinUAE uses direct memory access. Maybe Frode can tell more about this.

[Goingdown]

Out of curiosity, I tested this with my Opensuse 13.1 setup. FS-uae 2.3.13dev compiled from sources, 64-bit so no jit.

I don't see the cyclic slowdown at all, but I really don't have any idea if this is slow or fast?

I have Intel Core i7-2620M CPU @ 2.70GHz on my Thinkpad laptop. Cpu load in Linux host seems to be about 130-135% during the cputest. Screen vsync settings does not seem to affect this. Cpu setting was 68040, Amigaos 3.9 (Amikit)

[Der Wanderer]

This is half speed of WinUAE without JIT on my Thinkpad, and double-tipple speed of what FS UAE does on my machine. Makes perfectly sense if the cyclic slowdown was gone.
EDIT: The slowdown happens only on RTG. When running an AGA screen, the speed is constant at about 230 on my machine. I use the rtg.library that comes with WinUAE. Maybe here is a problem?

[Der Wanderer]

Nobody else has this problem? Help, please, this is serious! I need my UAE... ;-)

[FrodeSolheim]

I tested the benchmarking program on my Ubuntu 64-bit Linux with an Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz. I used an A4000/040 config with RTG enabled (it is basically the Amiga desktop from Amiga Forever...).

With FS-UAE 2.3.15dev 32-bit with JIT I got an average score of 56. A bit oscillation, so the graph is more like a band than a line, but relatively thin. With JIT disabled (both 32-bit and 64-bit versions) I get about 300. The line is more or less straight, no cyclic slowdowns.

I didn't run the same tests in WinUAE, but presumably and judging from your benchmarks, WinUAE would be a lot faster. I am not really surprised by that (see my previous comments). I'll be able to run tests on a Macbook Pro later and see if I can reproduce there.

Originally Posted by jbl007

uae_comp_trustlong=direct # this one crashes using 68040
[/CODE]

I think I figured this one out. As I understand it, the kickstart runs a series of memory probing (presumably using longs) to check for valid memory. However, the way memory management is done in FS-UAE currently - with a large allocated memory space - the JIT memory accesses basically never fail (unless the pointer is really weird). So the signal handler which is supposed to catch these illegal accesses never runs.

Until memory management is improved, using this might work and give a performance boost (haven't checked):

uae_comp_trustlong=indirectks

As I understand it, it should force memory accesses from kickstart code to be indirect, and direct otherwise. But since most illegal accesses will not currently be caught, using indirect access is much safer...

Originally Posted by Der Wanderer

no UAE (ed: AHI) audio

Good news, ahidsound_new.cpp from WinUAE is already implemented against OpenAL, so I should be able to "borrow" this with relatively little effort thanks to Toni

Don't expect any big solutions to any of these tomorrow or anything. Some of these issues can be rather major to fix / improve.

But fortunately Christmas is more or less here, so that may give me some opportunities to look at these issues in detail. I have already merged WinUAE 2.7.0 code in a separate code branch, and can work further on that branch while letting the existing development branch stabilize for an upcoming 2.4.0 release.

[jbl007]

Hm, I don't get huge slowdowns at all. Using RTG/JIT makes no difference at all. I (almost) get a straight line. Only very small variations using JIT.
Tested using: Intel Core i5 fixed at 1.6GHz, Intel HD 4000, forced fs-uae 2.3.15 to one core, Linux kernel 3.12 BFS.
Results:
jit: 119
no-jit: 686
RTG is only a little lower, I testet it with preinstalled AmigaSYS4E-UAE.hdf. It runs some stuff in the background...

But I can confirm fs-uae is much slower than winuae. For example calculating the predefined picture "Aurora" with ChaosPro fs-uae takes 30 seconds, winuae only needs 11s.

[jbl007]

"indirectks" seems to work so far. At least it boots now.

Again: Thanks for all your work, Frode (and Toni of course).

I did some DMA/non-DMA comparisons some month ago. The speed gain wasn't that great.
I set up an A1200/020 "real speed" and recorded host cpu usage every second running some scene demos. The difference was quite small.

[Der Wanderer]

The faster the system, the more "noise" you get in the benchmark, because a short distraction of the host from the emulation causes relatively seen more "damage". A really slow system wont show much difference if Windows is doing something quickly in the background. So what you report is normal.

What is NOT normal is, if you get different speeds over time, or this cyclic behaviour that is not explainable by something running in the BG. Again, the graph is logarithmic, means that in my benchmark the CPU fluctuates drastically from "regular" speed to almost freeze.

If you all guys don't see this on your computers, maybe it is my AmigaOS install that does something that is OK for WinUAE but not OK for FS UAE.

A good candidate might be the WinUAE optimized rtg lib:
rtg.library 40.3994

Which one do you guys use?
I will try to find out what the actual problem is. Again, on a native Screenmode I dont see this cyclic slowdown. But of course those screenmodes are not suitable for productivity.

Another thing:

What do you think makes FS UAE slower?
I am willing to help here, I am an experienced software developer.
I already thought about writing a "productivity" focused emulation from scratch, but that might take too much time. But maybe it makes sense to cut an emulator down from UAE that emulates only essential things and the rest is done RTG/AHI only for the sake of speed.
But this would be again a split. What about having a virtual Amiga Model in FS UAE that is tuned for productivity?

[FrodeSolheim]

Originally Posted by Der Wanderer

What do you think makes FS UAE slower

I think this was explained fairly well in a post further up:

Originally Posted by FrodeSolheim

There is basically two problems:

• Fastest-possible mode is done a bit hack-ish (=Make it more or less work, without fully understanding what is going on). A partial rewrite must be done after reviewing and fully understanding the fastest-possible code path.
• RTG refresh is linked to the chipset vsync, even though the RTG device may run independently of the Amiga chipset. This may or may not be a factor here, but the RTG code should probably be partially rewritten to make it work better (after actually trying to understand the corresponding WinUAE code ).

The point being that while work has been done to make "fastest-possible" mode and RTG work, not enough effort has gone into it to make sure it works optimally. Focus has instead been on making sure games work optimally. (Those are not mutually exclusive, but time spent on "games" vs "productivity" has certainly been disproportional).

One thing you can do which is helpful is to create minimal setups which test specific things or exhibit specific behavior, e.g. minimal zipped hard drives + config which:

1. Autostarts the benchmark software and exhibits the cyclic problem (on your computer). Then I can test the exact same setup and use it during debugging / development too
2. A minimal setup with AHI drivers and something which can play something with AHI (which works on WinUAE), which I can use to test AHI support while developing.

I think performance in fastest-possible-mode boils down to me or something else putting in sufficient effort to do fastest-possible-mode and RTG emulation "properly".