GEM Bench 3 - comments about CPU and FPU tests
==============================================

There are serious difficulties in benchmarking the CPU and FPU. The 68030 
which is found on the TT and Falcon and also on some accelerator boards 
has a built-in cache. If the test routine is cached it can be _very_ 
fast. If it isn't the 030 does not show its real capability. In addition, 
GEM Bench is compiled for any 680x0 processor and is not optimised for 
the 030, again not showing its real power. This however, reflect most 
ST/TT/F030, most are compiled in the same way. 

The FPU test is even more complex. A program can be compiled to use an 
FPU or to use the main processor. There is also a compromise setting 
which uses an FPU if one is found. In this mode, the FPU cannot show its 
true performance because of the overhead of the checks.
In addition, the 68881/2 have many functions such as log() and sine() 
built-in. These are processed very fast. The test in GEMBench was compiled 
to auto-detect and uses a mix of the built-in functions using double 
precision floats and also converts Fahrenheit to Celsius a few thousand 
times using single precision floats.

Some I/O mapped 68881/2 seem to crash when bombarded with data. This will 
cause GEM Bench to hang while testing. If this happens, I have included a 
file called IEEE.RUN. To use it rename AUTOFPU.RUN to AUTOFPU.RUX and 
then rename IEEE.RUN to AUTOFPU.RUN. This causes GEM Bench to ignore the 
FPU. The result it produces will then be based on the main CPU and will 
not use the FPU at all, but at least it will not hang.

The most surprising discovery was that TTs vary in speed. Some TTs can be up 
to 20% faster or slower at some functions compared to others.

Ofir