0.5 Benchmark methods

This chapter describes the benchmarking methods used to evaluate the performance and accuracy of various FFT implementations throughout this thesis.

The two architectures of interest are the Intel x86 architecture and the ARM architecture. A comprehensive set of results collected from a wide range of machines implementing these architectures is presented in Results and discussion , but throughout the rest of the thesis, benchmarks are performed on an Apple Macbook Air 4,2; a widely available and currently state-of-the-art machine that is equipped with an Intel Core i5-2557M. [link] summarizes the specifications of the machine.

For the x86 benchmarks, an existing framework called BenchFFT   [link] was used. For the ARM benchmarks, which were performed on iOS devices, there was no existing FFT benchmark software, and so an application was written for this purpose, which is described in "ARM architecture" .

X86 architecture

The x86 benchmarks were performed with BenchFFT, a collection of FFT libraries and benchmarking software assembled by Frigo and Johnson, the authors of FFTW  [link] . The benchmarks in BenchFFT use timing and calibration code from lmbench , a performance analysis tool written by Larry McVoy and Carl Staelin  [link] .

Timing

BenchFFT measures the initialization time and runtime of an FFT separately. The initialization time is measured only once, and thus outliersdue to effects from external factors such as OS scheduling are occasionally observed. Routines from lmbench are then used to calibrate the minimum number of FFT iterations required for accurate measurementusing the gettimeofday function. Finally, the time taken to run the minimum number of iterations is measured eight times, from which the minimumtime divided by the number of iterations is used, in order to factor out effects from external factors.

The minimum time for a transform is then used to determine a scaled inverse time measurement, sometimes known as CTGs. CTG are defined as:

for complex transforms and

for real transforms, where $t$ is the time taken to run one transform (in seconds). Unless the Cooley-Tukey radix-2 algorithm is used, a measurement expressed in CTGs is not an actual FLOP count – it is a roughmeasure of an algorithm's efficiency relative to the radix-2 algorithm and the clock speed of the machine.

When a transform has several variants (such as direction or radix), BenchFFT reports the speed of the FFT as being the fastest of the possible options.

Accuracy

To measure the accuracy of a transform, BenchFFT compares an FFT with an arbitrary-precision FFT computed on the same inputs, and reports therelative RMS error. The inputs are pseudo-random in the range $[0.5,0.5)$ and the arbitrary-precision FFT has over 40 decimal places of accuracy.

When a transform has several variants (such as direction or radix), BenchFFT reports the accuracy as being worst of the results.

Compiling

Except where otherwise noted, ICC version 12.1.0 for OS X was used to compile 64-bit code. For OS X builds, the compiler flags used were “-O3”,while “-O3 -msse2” (or equivalent) was used for Linux builds. In the cases where the FFT uses AVX, the code is compiled with “-xAVX” or“-mavx” (depending on compiler).

Some libraries included in the BenchFFT software have their own compilation scripts which override the defaults, and in the case of commercial libraries(such as Intel IPP and Apple vDSP), the compiler flags are of little consequence because the libraries are distributed in binary form.

Data format

FFT libraries use interleaved format and/or complex format to store the data. In the case of interleaved format, the real and imaginary parts ofcomplex numbers are stored adjacently in memory, while in the case of split format, the real and imaginary parts are stored in separate arrays.

The majority of FFT libraries use interleaved format to store data. In the case where the library supports interleaved or split format, BenchFFT uses interleaved format. However there are a few libraries that only supportsplit format, and in theses cases it should be noted the results are not strictly comparable (Apple vDSP is one such case).

Arm architecture

There was no existing FFT benchmarking software for iOS on ARM devices, and so a benchmarking tool was written. The tool runs the benchmarking in athread of normal priority.

Compiling

The code was compiled with Apple clang compiler 3.0 for ARMv7 targets running iOS 5.0. The compiler flags used were “-O3 -mfpu=neon”.

Timing

The Apple A4 and A5 SoCs are built around the ARM Cortex-A8 and Cortex-A9 cores, which have hardware cycle counters that can be used for precise timing.The cycle counter control registers can only be accessed in kernel mode, and so the high resolution timer available through the mach_absolute_time function was used instead.

For a given size of transform, a calibration routine determines the number of iterations that must be run such that the total runtime is approximately onesecond. After calibration, each FFT to be evaluated is run for the pre-determined number of iterations – this loop is run eight times, and thefastest time divided by the number of iterations is taken to be the FFTs runtime. By running each FFT for approximately one second, and repeatingthe measurement eight times to find the best time, the effects from external factors such as OS scheduling are minimized. As with BenchFFT, the time isexpressed in CTGs.