In the next two posts we’ll take a look at the Fibonacci algorithm used in a few other posts and see just how fast we can make it by looking at loop implementation, data type usage, and assembly code optimizations. In this first post we’ll take a look at some basic timing code, what gcc will do for us using the -O2 flag, then in the second post, see what we can do (if anything) to improve upon the generated code.

The Algorithm
The traditional use of the Fibonacci sequence is to show off the use of recursive function calls. The only problem with this is for every recursive call we dump the result of the previous call back on the functions call stack. For a few recursions this isn’t that bad, but in the case of a Fibonacci sequence it can lead to millions of calls and loads of memory–the most common end result then is too many calls will simply stall or crash the application.

The solution then is to use an iterative approach to solving the sequence.

Recall that the fib sequence is simply the sum of the previous two numbers in the sequence:

1+1=2, 1+2=3, 2+3=5, 3+5=8, 5+8=13, 8+13=21 [...]

For the sake of my implementation, we need to tell the loop how many times to run, and to shift the variables values down by 1 for each loop.

So on the first turn we set x and y to be 1 and 1 respectively. We then add them together, placing the value into a third variable.

We then swap the values of x and y down “1″, with x getting y’s old value and y getting z.

So how can we make this run as fast as possible? The first step is to figure out how fast it currently is. With modern CPU’s being as fast as they are seconds and milliseconds simply won’t do. Thus, we need to look at the finest grain counter an x86 CPU offers: CPU clocks.

To count clocks we’ll implement a CPU clock counting benchmark routine valid on gcc and x86-64 hardware:

The basic idea is we define a number for how many tests to perform, then loop over the code this many times. On each iteration we call our inline rdtsc() routine which is written in assembly. It’s important to note that with modern processors we need to serialize the instruction stream (via CPUID), as well as issue clobbers for the effected registers from the CPUID call. We’ll also measure the overhead of calling CPUID and subtract this from the final result. In the end this routine allow us to get a good feel for how many CPU clocks our code consumed.

Finally, as a general point of interest, context switches present in all modern operating systems can and will effect the clock count of very large functions. Thus, in our case we make sure to only benchmark small sections of code.

With our counting routine ready for action the first thing I wanted to look at was the base performance. Running through the first 8 iterations shows:

Overhead:440 Clocks: 363
Overhead:440 Clocks: 286
Overhead:440 Clocks: 407
Overhead:440 Clocks: 308
Overhead:440 Clocks: 286
Overhead:440 Clocks: 286
Overhead:440 Clocks: 286
Overhead:440 Clocks: 286

In other words, after a cache warm up period we stabilize at 286 cycles.

We’ll then add the -O2 optimization flag to the compiler directives (in NetBeans, open your projects options page and select the C++ Compiler options > Additional Options) and see what we get:

Overhead:429 Clocks: 121
Overhead:429 Clocks: 99
Overhead:429 Clocks: 66
Overhead:429 Clocks: 55
Overhead:429 Clocks: 66
Overhead:429 Clocks: 55
Overhead:429 Clocks: 66
Overhead:429 Clocks: 66

To make sense of this we’ll check out the assembly for each:

First, the unoptimized version:

And the -O2 optimized version:

The first thing that jumps out is the loop counting–whereas in the unoptimized version we count using the 16-bit registers against main memory, the optimized version adds ‘logic’ to the process, using cmpq to check an immediate value from a register (%rax).

This explains some of the speedup, but not all. The get to bottom of why the optimized code is so much smaller (faster) we can take a huge hint from the number of raw instructions, of which the optimized code of course has far fewer.

Part of this is a side-effect of the 64-bit architecture we’re compiling too, as %rdx and %rbx are leaq’d to %rcx to produce code which stores loop values in registers at all times, as opposed to the unoptimized code which continually pushes values to the call stack. This eliminates almost all of the movq’s which certainly helps, but far more importantly, we no longer access main memory.

All that said, it still doesn’t explain everything in terms of raw performance.

The big hint comes from recompiling the application to use only 4 Fibonacci loops. It’s a bit hard to see, so I’ve added an intermediate asm(“nop”) in the loop so it becomes clear:

gcc has unrolled the loop for us. Of course we only have so many registers, so one more loop to make 5 means we lose the unroll, and we’re back to standard loop code.

This is related to another important rule -O2 brings to the mix, which is if we remove the call to save our values in values[n], -O2 literally removes our code from the final assembly file:

Generates:

If however, we add a: cout << y; call after our loop, we generate:

In other words, the secret to the speed-up is in -O2 mode gcc adds just enough code to get the correct result, but nothing more. We’ll see this time and again when using optimizations, gcc stripping away the fat and making intelligent decisions based on your actual code, as opposed to blindly creating assembly that fits the most general scenario.

That said, nothings stopping us from rewriting the code using hand-crafted assembly to match the -O2 version, though with -O2 being 3 characters away, one could ask why bother…though we will anyway in the next post.