How to get maximum performance out of UAE-JIT ============================================= A) How to disable the configuration checks in UAE-JIT ----------------------------------------------------- If you are reading this, chances are that UAE-JIT told you that your configuration is suboptimal, and quit. First of all --- if, for whatever reason (benchmarking?), you want to use such a configuration, you can disable the check by adding compforcesettings=yes to your UAE config file. However, please read the rest of this README, because otherwise you might experience stability problems in addition to the non-optimal performance! B) Most direct memory access ---------------------------- Part of what makes UAE-JIT fast is that, for most memory accesses, it replaces UAE's traditional, function call based routines with x86 instructions that directly access the host memory. In order for this to work, UAE-JIT performs some slightly convoluted mapping magic, using Linux' SYSV shared memory segments. It is possible for that magic to fail. That has two consequences: * Emulated Memory access will be slower than it could be. * More importantly, you might experience occasional crashes. The crashes result from UAE-JIT trying to access Amiga "memory" that in reality is an area of memory mapped I/O. UAE-JIT tries to guess which instructions access I/O and which access real memory, but it can and does occasionally get it wrong. Usually (when the magic succeeds), there is a safety net that catches those mis-guessed accesses, simulates their effect on the emulation, and causes UAE-JIT to "guess again". THIS SAFETY NET IS UNAVAILABLE WHEN NOT USING THE MOST DIRECT MEMORY ACCESS, and thus things might crash. Here is a list of reasons why you might experience such problems, sorted by likelyhood (i.e. most probably, the first one is the reason): * You are using a large amount of memory for z3mem (like 64MB), and your linux kernel has a smaller limit on the maximum size of a SYSV shared memory segment (see "cat /proc/sys/kernel/shmmax"). Solutions: - decrease the amount of Z3 memory - increase the maximum size of shared memory segments by issuing echo 67108864 >/proc/sys/kernel/shmmax while logged in as root. 67108864 is 64MB, i.e. 64*1024*1024. Of course, you can set it to other values, if you want to, it just has to be at least as large as your Z3 mem * Your system is generally short on memory Solution: - Add RAM - Add extra swap space - Reduce memory sizes in UAE config file * You are running too old a kernel, which doesn't support some of the needed functionality and/or uses a memory mapping not suitable. I am not aware of any such kernels, but I am sure there are some Solution: - upgrade your kernel ;-) * Something else Solution: - add the following lines to your UAE config file: comptrustbyte=indirect comptrustword=indirect comptrustlong=indirect compforcesettings=yes Performance will be *much* worse than optimal, and crashes are still at least possible, though not likely. This should only be a last resort, if nothing else helps. If you need to do this, please tell me (bmeyer@csse.monash.edu.au) about it (because I intend to remove those options eventually if nobody is using them)! In summary, you *really* want to have the most direct memory access happening! C) comptrustxxxx Settings ------------------------- UAE-JIT "guesses" which emulated 68k instructions access real memory, and which access memory mapped I/O. Depending on those guesses, it compiles them into native code differently. The comptrust* configuration parameters allow you to override those guesses. If, for example, you put comptrustbyte=indirect into your config file, then UAE-JIT will treat *all* byte sized memory accesses as accessing memory mapped I/O. Of course, this will impact performance. As explained in the previous section, there is now a safety net that correctly handles the cases where UAE-JIT guessed "real memory", but reality was "memory mapped I/O" (such cases would crash earlier versions of UAE-JIT). Thus, these configuration options are obsolete, and should be left at their default values of "direct". These Options will probably go away sometime in the future, so making sure you use the default settings will not only give you best performance, but will also ensure that you won't be unpleasantly surprised when the default settings become hardcoded behaviour in future versions of UAE-JIT. If you find a reproducable crash while using the most direct memory access which can be avoided through comptrust* settings, that is a BUG which I need to know about! In that case, please email a detailed description to bmeyer@csse.monash.edu.au. D) The compnf Option -------------------- UAE-JIT tries to avoid generating 68k flags that are never used. Flag generation (and storage) takes time, so avoiding it when it isn't needed speeds things up. However, it is possible that I screwed up, and that it might be over-aggressive about this --- which might mean that some needed flags are not generated. That's what the compnf ("nf" for "noflags") Option is for. Putting compnf=no into your config file (and also "compforcesettings=yes" to make UAE-JIT accept it) will disable this feature. Of course, it will also reduce performance. This option is like the comptrust* options; It will eventually go away, and the default ('yes') will become hardcoded behaviour. If you find any software that behaves differently with this set to 'no', it's a bug and I need to know about it (so that I can fix it). E) The cache flush mode ----------------------- UAE-JIT now tries very hard to avoid recompiling code that doesn't need a recompile. If you have comp_flushmode=hard in your config file, all compiled code will get discarded each time the 68k processor issues an icache flush. That's normally not much of a problem, but if you are running a Mac emulator inside your Amiga emulator, there will be lots and lots of cache flushes, and you really really need to use "soft" rather than "hard". F) FPU Emulation ---------------- JIT FPU emulation is still very new and not very mature. It's almost certain to be even fuller of bugs than the non-JIT FPU emulation. So if you suspect that the JIT-FPU emu is causing you problems, put compfpu=no into your UAE config file. Note that eventually (when things have matured a bit), UAE-JIT will require the "compforcesettings=yes" to work without the JIT-FPU, and ultimately the option is likely to disappear. G) Console output ----------------- Due to its pre-Beta status, UAE-JIT still outputs a lot of info useful for debugging to the console it was started from. In most cases, that shouldn't have any significant effects on overall speed, but there are exceptions. If you suspect that console output is slowing you down, try running like this: uae -f config_file 2>/dev/null >/dev/null However, that way you won't get *any* output. In particular, if things go wrong, and you experience a crash, you won't have any info to mail me, so it will be much harder for me to fix what caused your crash. So please only do this if it really helps your performance!