        VUCAKO Bench
        ============

Bench is simple benchmark program for at least 32-bit computers.
It consists of several tasks which are designed to measure
performance of CPU, FPU, main memory, memory cache and file-system.
Bench is a "Open Source" program, see "copyright.txt" for details.

Configuration: all configurable items are included in the
first part of "config.h" file. Check three typedefs:
"int32" (32-bit signed integer), "unsigned32" (32-bit
unsigned integer), "byte" (unsigned 8-bit integer).
"double" has to be 64-bit long (IEEE 754) floating-point
number.

Makefile: distribution archive contains "Makefile"
in UNIX (Linux) format. Ysou should set the best possible
optimalization switches for your platform/compiler..

Individual results are identified by "cpu-description" string
and "clock" - effective number of cpu clock speed in MHz
(clock speed of single processor on SMP systems).
  Actual result file is "results.txt", new results are appended
to this file. If test suite is run more than once, result file
holds the best times only. It is recommended to run each test
at least 5 times to reduce effect of various fluctuations
(especially on Win32 systems with bad system-time measuring).
File "enhanced.txt" contains history of all best results.
  "clock" and "cpu-description" records are stored in "cpu.txt"
file. Program reads only the first record: 1st item holds
an e-mail address (and is ignored), 2nd item is "clock",
the rest of a line is interpreted as "cpu-description".

Results of test runs are printed in form: "elapsed time: TIME,
(act RATIO %), ref: REF". TIME is total cpu-time in seconds,
RATIO is ratio of actual time compared to another result record,
REF is reference number which eliminates nominal processor
clock-speeds (in MHz). Architectures with different clock-speeds
are comparable using this REF number (smaller values are
better).

Script "run": simple C-shell script runs each test three times.
It is recommended to run it at least two times in environment
which is as close to "single-users mode" as possible.

If you get results on some interesting/new architectures,
please send me the "result.txt" file (or "enhanced.txt"):

mailto:Josef.Pelikan@mff.cuni.cz
http://cgg.ms.mff.cuni.cz/~pepca/bench/

Java version (JDK1.1 compatible) is included in "jbench"
directory.


    Command-line options:
    ---------------------

bench [-h] [-l[s]] [-m <result-file>] [-b] [-s{a|d}{t|r|c}] [-r{m|v|d}]
      [-i <test>] [-t] [-r <reg-exp>] [-c <clock> ["cpu-description"]]
      [<mask>]

    -h      print help message (this text)

    -l[s]   don't run any tests, print result table(s) only
            "s" generates "spread-sheet readable" output

    -m <result-file> merge the given result file into "results.txt"

    -b      brief mode (don't print old results)

    -s{a|d}{t|r|c}
            sort results (ascending/descending, time/ref/clock)

    -r{m|v|d} <bytes>
            restrict tests according to physical RAM (m),
            virtual memory (v) or free disk space (d).
            <bytes> is number of bytes, examples: 256k, 64m, 2g

    -i <test> run only the given test (<test> number - see below)

    -t      self-test (pseudo-random generator etc.)

    -r <reg-exp> restrict result table to systems matching <reg-exp>
            (valid only for "-l" listing)

    -c      system-description:

      <clock> is CPU clock in MHz (see the 2nd column of "cpu.txt")

      "cpu-description" is arbitrary string (abbreviations are preferred,
                        see "cpu.txt" ignoring first two columns)

      if -c is not specified, the first line of "cpu.txt" will be read

    <mask>  is bit-mask (hexadecimal number 0xNNNN can be used):

       1. 0x0001 .. Eratosthen (5555555-th prime number)
       2. 0x0002 .. Transposition of 16MB image (uses two buffers!)
       3. 0x0004 .. Transposition of 64MB image (uses two buffers!)
       4. 0x0008 .. Arbitrage sequence lookup (double[12][12] matrix)
       5. 0x0010 .. Needle-throwing simulation (Monte-Carlo, 100M iterations)
       6. 0x0020 .. Fast memory-copy (two 16 MB arrays, 100 iterations)
       7. 0x0040 .. Monte-Carlo form-factor (50M iterations)
       8. 0x0080 .. Merge-sort on disk (double[8M] array)
       9. 0x0100 .. Wavelet (T-S) transform in memory (int32[4M-2K] arrays)
      10. 0x0200 .. Wavelet (T-S) transform on disk (double[16M-128K] arrays)
      11. 0x0400 .. Adaptive K-D tree on disk (150K operations)
      12. 0x0800 .. Quick-sort in virtual memory (double[8M] array)
      13. 0x1000 .. Quick-sort in virtual memory (double[32M] array)
      14. 0x2000 .. Quick-sort in virtual memory (double[128M] array)
      15. 0x4000 .. Garbage collection test in 16MB of VM
      16. 0x8000 .. Regular expression test (16k matches on 32-bytes strings)


    List of tasks in version 1.008:
    -------------------------------

 1 (mask 0x0001): Eratosthen
                  ----------
   Finds the 5555555-th prime number.
   Performance: CPU, memory system
   Memory: 12.5 MB
   Disk: no
   Result: the 5555555-th prime number is: 96210113
   Java: -ms32m -mx32m

 2 (mask 0x0002): Transposition of 16MB image
                  ---------------------------
   Transposes a 4096x4096 byte-image in main memory (96 times).
   Performance: CPU, memory system
   Memory: 32 MB
   Disk: no
   Java: -ms64m -mx64m

 3 (mask 0x0004): Transposition of 64MB image
                  ---------------------------
   Transposes a 8192x8192 byte-image in main memory (24 times). Very time
     consuming task on systems with <=128MB RAM!
   Performance: CPU, memory system, virtual memory system
   Memory: 128 MB
   Disk: virtual memory only
   Java: -ms168m -mx168m

 4 (mask 0x0008): Arbitrage sequence lookup
                  -------------------------
   Finds the best arbitrage-sequence in a set of 12 currencies.
     Actual exchange rates are defined by a 12x12 double matrix, maximum
     length of arbitrage sequence is 12.
   Performance: CPU, FPU
   Memory: <3 KB
   Disk: no
   Result: arbitrage profit: 1.882, seq: 10 5 8 12 11 2 7 1 4 9 6 10
   Java: -ms32m -mx32m

 5 (mask 0x0010): Needle-throwing simulation
                  --------------------------
   Does Monte-Carlo simulation of "needle-throw" experiment: a needle
     of length A falls to a regular infinite pattern of parallel lines
     with distance A. The goal is to determine probability of needle-line
     intersection.
   Performance: CPU, FPU
   Memory: <1 KB
   Disk: no
   Result: ratio = 0.636609330
   Java: -ms32m -mx32m

 6 (mask 0x0020): Fast memory-copy
                  ----------------
   The fastest memory-copy operation ("memcpy()" routine in libc) is
     performed on large arrays (16MB each).
   Performance: CPU, memory system
   Memory: 32 MB
   Disk: no
   Java: -ms64m -mx64m

 7 (mask 0x0040): Monte-Carlo form-factor
                  -----------------------
   Monte-Carlo computation of form-factor between parallel equal sized
     rectangles. 50 mil. rays are shot from one rectangle to another.
   Performance: CPU, FPU
   Memory: <1 KB
   Disk: no
   Result: Ffull = 0.1998385, Fhalf = 0.0686381
   Java: -ms32m -mx32m

 8 (mask 0x0080): Merge-sort on disk
                  ------------------
   Merge-sort of large disk file (double[8M] array of random numbers).
     double[1024] segments are pre-sorted in memory, "Merge-and-split" routine
     is used - 4 disk files of 32MB each are allocated.
   Performance: CPU, file-system
   Memory: 8 MB
   Disk: 128 MB in 4 files
   Result: OK
   Java: -ms32m -mx32m

 9 (mask 0x0100): Wavelet transform in memory
                  ---------------------------
   1D T-S lifting transform is performed on various int32[] arrays in memory.
     Equal number of arithmetic operations is used in every stage (for every
     array size) - partial times should represent efficiency of memory cache
     system.
   Performance: CPU, memory system, memory cache
   Memory: 16 MB max. (16MB, 8MB, 4MB, ... 8KB)
   Disk: no
   Java: -ms32m -mx32m

10 (mask 0x0200): Wavelet transform on disk
                  -------------------------
   1D T-S lifting transform is performed on large disk files (double[] type).
     Lifting and unlifting uses only sequential data access. Equal number
     of arithmetic operations is used in every stage (for every array size)
     - partial times should represent efficiency of disk cache system.
   Performance: CPU, file-system, disk cache
   Memory: <1 KB
   Disk: 128 MB max. (128MB, 64MB, ... 1MB) in 3 files
   Java: -ms16m -mx16m

11 (mask 0x0400): Adaptive K-D tree on disk
                  -------------------------
   2D adaptive K-D tree is used for storing point data objects. Each object
     occupies 512 bytes of disk space, bucket (leaf node) size is 4KB (i.e.
     8 objects). 150000 operations (55% of insertions, 45% of searches) are
     performed. Disk file is cached in 8MB of main memory.
   Performance: CPU, file-system, disk cache
   Memory: 8 MB
   Disk: 57.3 MB max.
   Result: 95k, 79k, 108k, leaf nodes: 14606, hits: 83
   Java: -ms32m -mx32m

12 (mask 0x0800): Quick-sort in virtual memory
                  ----------------------------
   Quck-sort of small double[] array is performed. 64MB of virtual memory is
     used.
   Performance: CPU, memory system, [virtual memory]
   Memory: 64 MB
   Disk: virtual memory only
   Result: OK
   Java: -ms84m -mx84m

13 (mask 0x1000): Quick-sort in virtual memory
                  ----------------------------
   Quck-sort of middle double[] array is performed. 256MB of virtual memory is
     used.
   Performance: CPU, memory system, [virtual memory]
   Memory: 256 MB
   Disk: virtual memory only
   Result: OK
   Java: -ms320m -mx320m

14 (mask 0x2000): Quick-sort in virtual memory
                  ----------------------------
   Quck-sort of large double[] array is performed. 1GB of virtual memory is
     used.
   Performance: CPU, memory system, [virtual memory]
   Memory: 1 GB
   Disk: virtual memory only
   Result: OK
   Java: -ms1056m -mx1056m

15 (mask 0x4000): Garbage collection test in 16MB of VM
                  -------------------------------------
   Random binary tree updates are performed. Tree is constructed and truncated
     many times. Approximately 200 GC passes are forced (in Java).
   Performance: CPU, memory system, Java VM garbage collection / C++ memory
                management
   Memory: 16 MB (C++: <2MB)
   Disk: no
   Result: Garbage collection test in 16MB of VM (3766MB, max 1095KB)
   Java: -ms16m -mx16m

16 (mask 0x8000): Regular expressions
                  -------------------
   Random strings "(a|b){32,32}" are generated and tested against four regular
     expressions: "(.*a){16,16}.*" (at least 16 occurances of "a"),
     "(.*aa){8,8}.*" (at least 8 occurances of "aa"), "^(.*a)a[^a]a[^a]a^(a.*)"
     (three isolated "a" characters in one sequence),
     ".*(aaaa.*bbbb|bbbb.*aaaa).*" (string contains both "aaaa" and "bbbb").
   Performance: CPU, memory system
   Memory: <64 KB
   Disk: no
   Result: Regular expressions (16k,32): 0.5720-0.1073-0.1663-0.4233
   Java: not available yet
