It seem the JIT direct mode is not work in fs-uae. direct mode is important

[bernd roesch]

I get report of memory speed values from readlong around 500 mb, and a boottime of amikit of around 32 sec with a AMD 4* 3.2 GHZ 32 bit fs-uae on linux 64 bit. on winuae with 4*2.8 GHZ on windows 64 bit and uae 32 bit boot time is 11 sec. both directory file system.
It seem the JIT direct mode is not work in fs-uae. direct mode is important for good speed in JIT mode as High end amiga. it make all 2-3* faster.
How can this enable ?.

[jbl007]

Originally Posted by bernd roesch

How can this enable ?.

uae_cachesize = 8192
uae_comp_trustbyte = direct
uae_comp_trustword = direct
uae_comp_trustnaddr = direct
uae_comp_trustlong = indirectks

[amigafreak68k]

I believe, if this works, it only works on Windows. Just for information.

[bernd roesch]

The uae jit develop from Bernie, was on Linux. And this direct mem accesss feature work ok on Linux. On windows in 32 bit it was hard to implement. first there was a hack need to set the Z3 address space from 0x40000000 to 0x10000000. On 64 bit windows and 32 bit winuae this is not need, because available adress space is for 32 bit programs larger as on 32 bit windows. so a 32 bit linux program run on a 64 bit linux should work ok too.

[FrodeSolheim]

Originally Posted by jbl007

uae_cachesize = 8192
uae_comp_trustbyte = direct
uae_comp_trustword = direct
uae_comp_trustnaddr = direct
uae_comp_trustlong = indirectks

This should work on Linux. The reason direct memory access is not enabled by default is because the "segfault handler", whose purpose is to "intercept" illegal memory accesses by Amiga software does not work (yet) in FS-UAE, and any such illegal memory access will (most likely) cause FS-UAE to crash.

With everything set to direct, it will actually crash during Kickstart startup, because Kickstart code tries to write/read memory (probing for available memory), and when it probes too far, it crashes. Setting uae_comp_trustlong = indirectks works around this by ensuring that memory accesses (32-bit read/writes, which is used for probing) from kickstart code (only) is indirect.

So this will work... mostly... but a memory access to unmapped memory from an Amiga program will still cause FS-UAE to crash...

[FrodeSolheim]

Actually, I checked the code. It looks like support for indirectks was effectively removed from WinUAE 2700b6 (and thus also from later versions of FS-UAE). indirectks looks like it has now the same effect as (always) indirect.

[jbl007]

Originally Posted by FrodeSolheim

This should work on Linux.

It does. Amikit (copied to hdf) boots in 10 seconds on my system with DMA, and 20 without it. But overall speed increase (raw cpu power) isn't that big, far away from 2-3x...
I don't remember of any bad crashes, perhaps I was just lucky.

With everything set to direct, it will actually crash during Kickstart startup

Actually seems to work with A1200/020 and cpu_speed=max. I haven't found out if it is related to the different kickstart version or emulated cpu or something else.

It looks like support for indirectks was effectively removed from WinUAE 2700b6

Too bad. But partially supported DMA is better than no DMA.

[bernd roesch]

@jbl007 do you use 32 bit Linux or 64 bit linux for fs-uae

Originally Posted by FrodeSolheim

This should work on Linux. The reason direct memory access is not enabled by default is because the "segfault handler", whose purpose is to "intercept" illegal memory accesses by Amiga software does not work (yet) in FS-UAE, and any such illegal memory access will (most likely) cause FS-UAE to crash.

With everything set to direct, it will actually crash during Kickstart startup, because Kickstart code tries to write/read memory (probing for available memory), and when it probes too far, it crashes. Setting uae_comp_trustlong = indirectks works around this by ensuring that memory accesses (32-bit read/writes, which is used for probing) from kickstart code (only) is indirect.

So this will work... mostly... but a memory access to unmapped memory from an Amiga program will still cause FS-UAE to crash...

Is this only Problem of 64 bit linux when run 32 bit uae with Jit ?

If in 32bit linux the same i think you have not add the excpetion handler for Linux, from the old uaejit Bernie do.

I can confirm, that the old Linux UAE have a working exception handler for 32 bit linux, so uae Linux can work in direct mode without crash. first i use linux to see how exception handler on linux work. I have work together with Brian King to write exception handler for windows and i add winuaenforcer support. winuaeenforcer log the illegal mem access that trap into exception handler so it can output. winuae can never crash due to illegal mem access from amiga side.

I have not Linux install, but i told the Linux user to add the text

uae_comp_trustbyte = direct uae_comp_trustword = direct uae_comp_trustnaddr = direct uae_comp_trustlong = indirectks
He told me that he do this in the same file he write
uae_cachesize = 8192"Additional Configuration" "own config
Konfiguration"

or maybe there is a problem that on a 64 bit linux direct mode is not enable in general ?

I did not know about linux, if there can work 32 bit exceptionhandlers on 64 bit Linux.

[jbl007]

I use a 64bit Linux system with 32/64bit dual install of fs-uae.

[bernd roesch]

please try sysspeed on amikit in the low tab, with low memory benchmark. and use newest fs-uae

the values changes, because it is measure a very short time so do 2-3 tries

What Values you get with ReadFastl, writefastl, fast2fastl ?

what CPU you have ?

It does. Amikit (copied to hdf) boots in 10 seconds on my system with DMA, and 20 without it.

what do you mean with DMA ?
I do a test what speed diffrence hdf and directory filesys bring on boot amikit 8.5 on winuae. with hdf it is only around 2 sec faster on ssd and 5 sec faster on Harddrive ( 2 TB drive). but this is only the first try. when data is in cache, then harddrive with directory filesys is too around 2 sec slower as hdf. so use hdf is not worth the work, if uae use direct mode and JIT

[jbl007]

First I have to correct myself, AmiKit boot times with jit and jit+direct are nearly the same.

DMA == direct memory access
Isn't that the correct term for it?

I only copied my AmiKit install to hdf because I did'nt want to have thousands of amiga files on my hard drive, not for speed related reasons.

I tested 32bit and 64bit fs-uae executable and also jit and jit+direct mode (see screenshot). I can also upload module files if you want. I used a ClassicWB install to get the values, for some reason I had problems with AmiKit saving the modules.
CPU is a Core i5-3570K at 4.2GHz, Memory clock is at 1600MHz

Your Conclusion???

[FrodeSolheim]

Originally Posted by FrodeSolheim

With everything set to direct, it will actually crash during Kickstart startup...

I checked, and I have actually enabled the segfault handler for quite some time. It does not work properly however, so (all) direct does not work, but FS-UAE does not *crash* due to the segfault handler, it just misbehaves (Amiga reset loop, etc).

Originally Posted by bernd roesch

If in 32bit linux the same i think you have not add the excpetion handler for Linux, from the old uaejit Bernie do. [...] I can confirm, that the old Linux UAE have a working exception handler for 32 bit linux, so uae Linux can work in direct mode without crash.

Yes, the original UAE does have a working segfault handler. But in FS-UAE, it does not work in it's current state. Possibly due to later changes in WinUAE, without a corresponding change in the Linux segfault handler, or an error made by me when porting the WinUAE code - or a combination. In any case, the JIT segfault handler needs additional debugging / work in order to function correctly!

Originally Posted by jbl007

I tested 32bit and 64bit fs-uae executable and also jit and jit+direct mode

I did a few benchmarks of my own, in order to have a few "official" numbers and put speculation at rest (tested with AIBB on the same 64-bit Ubuntu Linux box), tests were run multiple times and a rough average was chosen):

                  64-bit     32-bit   jit indirect  jit direct (long=indirect)
AIBB emutest       152          145          1057         1400
AIBB dhrystone     187          171          910          1725
AIBB memtest       310          278          910           910

Since indirectKS does not work in the current versions, indirectKS == indirect, and the options listed earlier in this thread is effectively direct memory access except for long (32-bit) read/writes.

I then re-enabled support for indirectKS in FS-UAE (reverting the change from the aforementioned WinUAE version), and ran the benchmarks again:

         jit direct (long=indirectKS)
AIBB emutest       1600
AIBB dhrystone     2200
AIBB memtest       5700

("memtest" in AIBB obviously uses mostly/only 32-bit read/writes ;-))

[jbl007]

Originally Posted by FrodeSolheim

("memtest" in AIBB obviously uses mostly/only 32-bit read/writes ;-))

Until Commodore builds 64bit Amigas...?

910 vs. 5700 in AIBB memtest. That's quite an improvement!

But real world benchmarks are more interesting/useful. For example running a demo in warp mode and measure real time. This would give us the real emulator speed including all emulated hardware. How about an option to start emulation in warp mode? uaectrl could be used to quit after the demo has ended.

[bernd roesch]

Originally Posted by jbl007

First I have to correct myself, AmiKit boot times with jit and jit+direct are nearly the same.

DMA == direct memory access
Isn't that the correct term for it?

I only copied my AmiKit install to hdf because I did'nt want to have thousands of amiga files on my hard drive, not for speed related reasons.

I tested 32bit and 64bit fs-uae executable and also jit and jit+direct mode (see screenshot). I can also upload module files if you want. I used a ClassicWB install to get the values, for some reason I had problems with AmiKit saving the modules.
CPU is a Core i5-3570K at 4.2GHz, Memory clock is at 1600MHz

Your Conclusion???

your reportet amikit boot time is too slow for a speed monster 4.2 GHZ machine. My 2.8 GHZ have only 1300 MHZ mem btw. the sysspeed test seem too short for your fast machine. because uae can not exact short times measuring, you get much 0 values. for real world test, you can use on amikit ffplay and play a video. the framerate at which the video is play, can output. or you can encode mp3 and here too the time is output

DMA == direct memory access is correct.

But how do you switch DMA on or off to get the diffrent results ?. I ask, because i miss something, and when i can enable DMA with hardfile it work faster.

I make music with hd.rec, its a virtual music studio, there are benchmark option in effect. with indirect mem for the reverb pro result is 10.7% CPU time is need(depend on realtime 44.1). With direct on, only 1.7% CPU time the reverb need. the measure time is long so uae can result exact values

here can download, if somebody like make music, or like a precise real world benchmark program ;-)

http://sourceforge.net/projects/hd-rec/

the software synthesizer can load sf2 files and there is also a GUI benchmark, with that you can load a demo project in and it is output redraw time of the tracks. SO this measure real world graphic performance

[jbl007]

Originally Posted by jbl007

How about an option to start emulation in warp mode?

Not really needed. We can call "uae-configuration warp true" from Workbench/scripts.

And not only that. We can also so "uae-configuration comp_trustlong direct" to enable full direct mode.

How cool is that!?

Originally Posted by bernd roesch

your reportet amikit boot time is too slow for a speed monster 4.2 GHZ machine.

Sorry, but I don't care. Like I said, I put in in a hdf with FFS filesystem which is known to be quite slow. I think I'll bench some demos in warp mode later to get more interesting results.

But how do you switch DMA on or off to get the diffrent results ?

Use different config files. Use "cachesize=8192" to enable JIT only. Use the uae_comp*- options I posted obove to (partially) enable DMA. To get full DMA download winuae.zip and put Amiga Programs/uae-configuration in your sys:c/ on the amiga side. Then write "uae-configuration comp_trustlong direct" in your startup-sequence.

http://sourceforge.net/projects/hd-rec/

Needs some additional libs I don't have right now...

[bernd roesch]

in hd-rec normally all libs should be in. also amikit have the libs

here is a full archive too
http://hd-rec.de/HD-Rec/index.php?site=home

FrodeSolheim
Yes, the original UAE does have a working segfault handler. But in FS-UAE, it does not work in it's current state. Possibly due to later changes in WinUAE, without a corresponding change in the Linux segfault handler, or an error made by me when porting the WinUAE code - or a combination. In any case, the JIT segfault handler needs additional debugging / work in order to function correctly!

I remember, Linux uae from bernie segfault handler work only with 020/881. so for other 68k cpu to emulate, the handler need change. you can see if the jump into handler work ok, and give out correct results, when you add the winuaeenforcer code to linux uae. if winuae enforcer show correct address, registers (check with the lawbreaker testprogram from amiga dev disk), and uae fs freeze, then the return to code is wrong. i remember for windows there need do some stack trick and the stack frame of X86 CPU need set to other address.

to enable winuaeenforcer you need start the winuaeenforcer 68k program that is attached in winuae amigaprograms

[jbl007]

Originally Posted by bernd roesch

in hd-rec normally all libs should be in.

You need to install camd.library, zlib.library, jpeg.library and (optional) ptplay.library

I exported the demo project "hq sweeper demo3" to a 44.1kHz 16bit wave file for speed testing. Results:

64bit executable: 16 mins. + 55 secs.
32bit executable: 12 mins. + 10 secs.
jit: 36 secs.
jit+direct: 15 sec.

[bernd roesch]

In the 64 bit fs-uae version the JIT do not work. same in winuae too. 64 bit winuae have no working jit.

have you render to ram disk ?

I render to amiga RAM disk. My results are

JIT indirect 53 sec
JIT direct 15 sec

With JIT indirect your machine is 47% faster, which look ok, because your CPu is faster GHZ and more modern. modern intel give also more performance /MHZ

Seem your JIT direct mode work not fully ok, because my machine is a little faster. I try several time, and it need 14 sec or sometimes 15 sec. but never more as 15 sec.

what 68k CPU you switch on ?

I test with 68040, but i give a quick try in 68020/68881. speed is same.

see screenshot of my

EDIT: there is also GUI benchmark. can do with sweeper HQ project to compare. make the window full hd size, and press the button (see my mousepointer right below). then the takes are size so Song fit full window.

now choose in hd-rec menu beta, gui benchmark and look at time. 1. redraw need 27 ms. see screenshot

[jbl007]

Originally Posted by bernd roesch

have you render to ram disk ?

No, I used a directory mounted hdd. Rendered to ramdisk it's 2-3sec. faster. Now it's 12-13 sec. with jit-direct.

I think this programm is a little bit special and heavily depends on memory speed. This could explain why:
1.) 32bit non-jit is faster than 64bit non-jit (Usually 64bit is ~5% faster with many other applications)
2.) jit-direct is much faster than jit-indirect (Usually the difference isn't that big)

So 1300MHz (you) vs. 1600MHz (me) and 15sec. (you) vs. 13sec (me) looks right to me.

GUI speed is 10ms for one redraw.

[bernd roesch]

all programs that do much data calculations, and need longer time depend on memory speed. because when a program need long time, it must read lots data from memory. direct mode also increase lots, if decode/encode video etc. all this use many data. you can also test compile time with gcc. also big increase of direct mode

10 ms in gui speed really, seem linux is faster on GFX. i use in winuae direct 3d setting

but strange is, wy the linux user i know get not the fast speed you get with direct mode. maybe there is a config option that block direct mode. Please upload your fs-uae config file, and what version you use