This is a README file for Amiga port of BYTE Magazine portable
benchmarks. For more informations see README and bdoc.txt files. Original
files are available at ftp://byte.com/bench/


Contents

1. Introduction
2. Usage
3. Porting
4. Contact
5. History


1. Introduction

	I've been a reader of BYTE Magazine for a long time and I like it
very much. It used to cover Amiga from time to time and some very good
articles were published there (e.g. "The Object-Oriented Amiga Exec"). Today,
BYTE is a valuable source of informations about new CPUs, operating systems,
network technologies, etc.
	Several months ago BYTE created a new benchmarking standard called
BYTEmark (tm). These portable benchmark programs test computer's CPU and FPU
speed by executing real-world algorithms. This is BYTEmark port to Amiga,
done with SAS/C compiler.


2. Usage

	Five executables are provided:
NBench         - for Amigas with 68000 CPU and no FPU (mathieee.library)
NBench.020     - for Amigas with 68020 CPU and no FPU (mathieee.library)
NBench.020.881 - for Amigas with 68020 CPU and FPU
NBench.040     - for Amigas with 68040 CPU and no FPU (mathieee.library)
NBench.040.881 - for Amigas with 68040 CPU and FPU
	Run the executable appropriate for your computer (either from Shell or
Workbench). Please note that a file named 'nnet.dat' must be present in the
directory where executables exist. On slow computers (like my A1200 with FAST
RAM) it may take a few hours to do all benchmarks. Results are indexed
relative to a 90MHz Pentium. E.g. a score of 0.02 means that on a given test
your Amiga is 50 times slower than a 90MHz Pentium system, while a score of
2.0 indicates that your computer is twice as fast as a 90MHz Pentium system.

	Sample results obtained using 020 version of NBench on an A1200
(14MHz MC68020, 20 MHz MC68882) with 4MB of FAST RAM:

Using IEEE math (NBench.020):

BYTEmark (tm) Native Mode Benchmark ver. 2 (3/95)
NUMERIC SORT:  Iterations/sec.: 1.309980  Index: 0.033854
STRING SORT:  Iterations/sec.: 0.036165  Index: 0.015897
BITFIELD:  Iterations/sec.: 234792.492489  Index: 0.040274
FP EMULATION:  Iterations/sec.: 0.106421  Index: 0.051164
FOURIER:  Iterations/sec.: 5.937827  Index: 0.006723
ASSIGNMENT:  Iterations/sec.: 0.016969  Index: 0.064653
IDEA:  Iterations/sec.: 1.940385  Index: 0.029688
HUFFMAN:  Iterations/sec.: 1.292873  Index: 0.035928
NEURAL NET:  Iterations/sec.: 0.002372  Index: 0.004013
LU DECOMPOSITION:  Iterations/sec.: 0.066017  Index: 0.003898
...done...
===========OVERALL============
INTEGER INDEX: 0.035875
FLOATING-POINT INDEX: 0.004720
 (90 MHz Dell Pentium = 1.00)
==============================

Using 68881 math (NBench.020.881):

BYTEmark (tm) Native Mode Benchmark ver. 2 (3/95)
NUMERIC SORT:  Iterations/sec.: 1.250116  Index: 0.032307
STRING SORT:  Iterations/sec.: 0.035200  Index: 0.015472
BITFIELD:  Iterations/sec.: 228693.042185  Index: 0.039228
FP EMULATION:  Iterations/sec.: 0.104482  Index: 0.050232
FOURIER:  Iterations/sec.: 10.602037  Index: 0.012005
ASSIGNMENT:  Iterations/sec.: 0.016827  Index: 0.064110
IDEA:  Iterations/sec.: 1.923596  Index: 0.029431
HUFFMAN:  Iterations/sec.: 1.409290  Index: 0.039163
NEURAL NET:  Iterations/sec.: 0.006579  Index: 0.011131
LU DECOMPOSITION:  Iterations/sec.: 0.175353  Index: 0.010353
...done...
===========OVERALL============
INTEGER INDEX: 0.035622
FLOATING-POINT INDEX: 0.011143
 (90 MHz Dell Pentium = 1.00)
==============================

	As you can see, my A1200 is about 28 times slower than a Pentium
machine doing integer calculation, and about 90 times slower doing
floating-point calculations. What's more, floating-point performance
increases almost three times when using direct FPU calls!


3. Porting

	Since benchmarks are written in ANSI C they test not just CPU+FPU,
but rather compiler/CPU+FPU combination. When compiled with different
compileres, different results will be obtained.
	I've encountered very few troubles porting the code. I needed to
change some #define statements and replace all Func(); declarations with
Func(void); declarations, as well as add some casts to avoid compiler
warnings. I've also created SMakeFile. Dummy INCLUDE:mem.h file (which is
actually a copy of INCLUDE:strings.h) must be created to let the source
compile.
	One test (String Sort) is particularly slow. I suspect that this is
due to SAS implementation of memmove() function.


4. Contact

	Your opinions are welcomed! Send them (as well as comments, test
results, executables obtained with different compilers, etc.) to:

Michal Letowski
Przyjazni 51/17
53-030 Wroclaw
POLAND

or

pro37@ci3ux.ci.pwr.wroc.pl


5. History

Version 2.0 (6.11.95) - initial version, compiled from BYTEmark release 2
sources.

Version 2.1 (19.1.96) - .881 versions were unusable due to wrong options
setup. This is fixed now.

Version 2.2 (2.6.96) - stack usage reduced down to 4KB, more compiler
optimizations enabled.