Benchmarks regarding the Sather 1.1 compiler
Send questions and remarks to Claudio Fleiner.
On this page you will find links to several benchmarks that show the
impact of five different optimizations of the new 1.1 Sather
compiler. Results for the 1.0.8 Compiler are also available.
For more information about Sather check out the
Sather Home page at the International Computer Science Institute.
All benchmarks presented on this page were run on either Solaris 2.4 or
Solaris 2.5, using GCC version 2.7.1 on a Sparc 10 with 4 Processors.
The Benchmarks
For greatest flexibility and to select different options on how
to view the results, use the form based interface. If your computer does
not support forms, you can use the following pages:
Note that the parallel version of the program were run on a
4 processor shared memory Sparc running Solaris 2.5. There
are no benchmarks available for distributed pSather yet.
The Optimization Options:
- Inlining
Inlining replaces function and procedure calls by the body of
the respective function/procedure. It is also able to inline some
of the iterators.
- Move While! and Until!
If a while! or until! is at the beginning of the loop, this
option moves it to the end and encloses the loop in an if
statement. This allows us to move more loop constants and iter
initializations out of the loop.
- Hoist Iter Once Arguments
In many cases it is possible to move the initialization of once
arguments of iters out of the loop. This makes the loop smaller
and removes an if statement in the loop.
- Hoist Loop Invariants
Loop constants should be evaluated only once, outside the loop.
If this option is used, but not the preceding one, many
initializations of once arguments are still hoisted, although
this option is less aggressive than the one above.
- Common Subexpression Elimination
Common subexpressions are eliminated with this option, and
multiple writes are removed.
- Replace Iters
This option has been removed from the compiler, as the
new compiler supports now builtin iterators. Those iterators
are now inlined in any case (even when not optimizing).
Description of the Tables
Each line of the tables shows the result when using some of the
optimization options of the compiler. The options that are turned
on for each line are marked with a blue dot. A red dot (only used in
the impact tables) signifies
that this line shows the difference between two runs of the compiler,
once with this option turned off, and once when it is turned on.
To the right are the different measurments made. Each column is
divided into up to 4 subcolumns (the standard tables have just
the first two columns, but with the form interface you
can turn each column on and off individually).
- The first one shows the absolute value,
- the second one the relative value when compared with the standard compiler
(the one shown in row 1),
- the third one the difference between the standard compiler and this line
in absolute values
- and the fourth one the relative difference between the standard compiler
and this line.
Note that the impact tables will only show the last two subcolumns,
and instead of comparing the values with the standard compiler, they show
the difference introduced by using the option marked with a red dot.
The Measurements
- # [#]
This gives you the number of the row, and a unique number for
this combination of options of this row. This number
may be used to quickly locate the same row in other tables.
The impact table, where each row describes actually two rows, has
two numbers in the square brackest, one numbering the row if the
option with the red dot is not used, and one if it is used.
- Best Run
The time in seconds of the fastest run of the test program.
- Mean Run
This is the average time the program ran during the
measurements.
- Size
This is the size of the executable in KB.
- Compile Time
This shows how many seconds the compiler needed to compile the
benchmark program.
- Memory used by the Compiler
The number of KB used by the compiler to compile the
Sather program
