Previous | Table of Contents | Next |
This kernel has been used to assess the efficiency of the procedure-calling mechanism in ALGOL-like languages. The function has two parameters and is defined recursively. The function Ackermann (3,n) is evaluated for values of n from 1 to 6. The average execution time per call, the number of instructions executed per call, and the amount of stack space required for each call are used to compare various systems.
A listing of the benchmark program in SIMULA is shown in Figure 4.3. The value of the function Ackermann (3,n) is 2n+3 3. This knowledge is used in the code to verify the implementation of the benchmark. The number of recursive calls in evaluating Ackermann (3,n) has been shown by Wichmann (1976) to be
BEGIN INTEGER n; !Loop index; INTEGER j; !Function value; INTEGER num_calls; !Number of recursive calls; INTEGER k; !Contains 2**(n+3); INTEGER k1; !Contains 4**(n-1); REAL t1,t2; !CPU time values; INTEGER PROCEDURE Ackermann(m,n); VALUE m,n; INTEGER m,n; Ackermann := IF m=0 THEN n+1 ELSE IF n=0 THEN Ackermann(m-1,1) ELSE Ackermann(m-1,Ackermann(m,n-1)); !Main Program; k := 16; K1 := 1; !Initialize k and k1 for n=1; FOR n := 1 STEP 1 UNTIL 6 DO BEGIN t1 := CPUTIME; !Beginning CPU time; j := Ackermann (3,n); !Compute the function; t2 := CPUTIME; !Ending CPU time; IF j <> k-3 THEN OUTTEXT(Wrong Value); OUTTEXT(Net CPU Time for Ackermann (3,); OUTINT(n,1); OUTTEXT() is); OUTREAL(t2-t1,7,15); OUTIMAGE; Num_calls := (512*k1-15*k+9*n+37)/3; OUTTEXT(CPU Time per call:); OUTREAL((t2-t1)/num_calls.7,15); OUTIMAGE; ki := 4*k1; !Update k1 for the next n; k := 2*k; !Update k for the next n; END END |
FIGURE 4.3 SIMULA program to implement Ackermanns function.
(512 × 4n1 15 × 2n+3 + 9n + 37)/3
This expression is used to compute the execution time per call. For Ackermann (3,n), the maximum depth of the procedure calls is 2n+3 4. Hence, the amount of stack space required doubles when n is increased by 1.
Used at the British Central Computer Agency, the Whetstone kernel consists of a set of 11 modules designed to match observed dynamic frequency of operations used in 949 ALGOL programs. The kernel exercises such processor features as array addressing, fixed- and floating-point arithmetic, subroutine calls, and parameter passing. It has been translated from ALGOL to FORTRAN, PL/I, and other languages. A listing of the workload in ALGOL can be found in Curnow and Wichmann (1975).
The results of the Whetstone benchmarks are measured in KWIPS (Kilo Whetstone Instructions Per Second). There are many permutations of the Whetstone benchmark, so it is important to ensure that comparisons across various systems utilize the same source code and that the internal loop counter is defined large enough to reduce timing variability.
Despite its synthetic mix of operations, Whetstone is generally considered a floating-point benchmark and is mostly representative of small engineering/scientific applications that fit into cache memory.
The modules were designed to minimize the impact of known compiler optimizations. Newer compiler optimization techniques can significantly affect the execution time of this workload on a processor. It suffers from other problems of kernels in that there is no I/O and values of input parameters significantly affect the measured performance.
Developed by Jack Dongarra (1983) of Argonne National Laboratory, this benchmark consists of a number of programs that solve dense systems of linear equations using the UNPACK subroutine package. UNPACK programs can be characterized as having a high percentage of floating-point additions and multiplications. Most of the time is consumed in a set of subroutines called the Basic Linear Algebra Subprograms (BLAS), which are called repeatedly throughout the benchmark.
The LINPACK benchmarks are compared based upon the execution rate as measured in MFLOPS. The most popular variants solve a 100 × 100 system of equations, either in single or double precision, and have become one of the most widely used benchmarks to gauge engineering/scientific applications performance. For example, many finite element, finite difference, simulation, and regression analysis applications exploit LINPACK-like equation solvers.
Previous | Table of Contents | Next |