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 programs, 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