* Benchmark tests:

The benchmark tests are intended to check the behaviour of
optimisations in the compiler and rts. Use 'make bench' in this
directory or 'make benchmark' in the main build directory to run the
tests.

* Current tests:
** Ackermann
This tests performance with a highly recursive algorithm.

** Fibonacci
This is another recursion performance test.

** Heapsort
This tests array and mathematical comparison performance

** HTML
This tests the performance of the HTML construction and output used in
webprogs.

** Lists
This tests the performance of user-defined data types with large
amounts of data and argument projection.

** Lists2
An alternative implementation of Lists (this is approximately testing
the advantage of using a compiler-optimisable type, and some better
caching of notset values, compared to lists)

** Primes
A test of arrays and loops

** Random
This tests integer and float operations, and also global variable speed.

** Stringbuild
This tests construction of strings.

** Takfp
This tests recursive operations using floats

** Takint
Same as takfp, but using ints. Together with takfp gives a measure of
the relative speed of ints and floats.

* Adding additional tests

Additional tests should have a source file 'testname.k' that compiles
to a 'testname' executable. Simply add to the appropriate parts of
Makefile.in and reconfigure.

Tests must not write to stderr, though writes to stdout are
fine. Tests must also not rely on any checks removed by -nortchecks
(which is bad practice anyway), nor require any user input (either
from the keyboard, or command-line parameters).

* What do the results mean

The benchmark program first runs a simple C program to get a measure
of the computer's relative speed. It then runs a simple Kaya program
to check the startup time for Kaya apps. Using these figures, it then
normalises the time taken to run each test to give a performance
number.

Performance numbers are *not* generally comparable between tests (so
the ackermann test being faster than the lists test is not important)
but can be compared for the same test, and should be reasonably
comparable between different computers.

The lower the number the better, but what the number actually means is
debatable.

* Performance tests and 'cheating'

Yes, 'fibonacci' would be considerably faster if it had a cache in its
recursion. Adding the cache in the .k is cheating. Rewriting kaya so
that it detects it's a recursive function without side-effects and
automatically adds a little cache when compiling is not cheating
(though not necessarily a good idea either - who knows until someone
tries it...).

Of course, if there's an unintentional inefficiency in the
implementation (for example, if the ackermann implementation was set
up to stop tail-recursion working), that should be fixed.
