#include <stdio.h>
#include <stdlib.h>

int test_noRef(int value)
{
	return value + 1;
}

int test_ref(int &value){
	return value += 1;
}

int main(int argc, char *argv[]){

	int t = 1;

	for(int i = 0; i < 100000000; i++){
		//t = test_noRef(t);
		test_ref(t);
	}

	// final result = n loops + 1
	printf("%d\n", t);

}

This code is purpose built to thwart basic compiler optimizations. In particular the printf() call at the end prevents the compilers from simply skipping the entire function call block.

While simplistic, the basic idea is to see what optimizations each compiler performs and at what optimization level. Note that the LLVM/Clang suite can easily be installed on Fedora 15 by searching for LLVM. You’ll want to install LLVM and Clang:

No Optimizations

We start with a basic compile with no optimizations; in each case we’ll focus on test_ref() and test_noRef(). Please note I’ve removed the stack management code from these listings as they differ very little by compiler.

g++ main.cpp -S
clang main.cpp -S

[GCC]

_Z10test_noRefi:
.LFB0:
	movl	%edi, -4(%rbp)
	movl	-4(%rbp), %eax
	addl	$1, %eax
	popq	%rbp
	.cfi_def_cfa 7, 8
	ret

The noRef call in GCC moves our parameter to eax, adds 1, and cleans up the stack.

[LLVM]

_Z10test_noRefi:
.Leh_func_begin0:
	pushq	%rbp
.Ltmp0:
	movq	%rsp, %rbp
.Ltmp1:
	movl	%edi, -4(%rbp)
	movl	-4(%rbp), %edi
	addl	$1, %edi
	movl	%edi, %eax
	popq	%rbp
	ret

The LLMV code for the noRef() function is quite similar. The main difference is LLVM uses edi for the addition step, then pushes the result to eax before returning.

[GCC]

_Z8test_refRi:
.LFB1:
	movq	%rdi, -8(%rbp)
	movq	-8(%rbp), %rax
	movl	(%rax), %eax
	leal	1(%rax), %edx
	movq	-8(%rbp), %rax
	movl	%edx, (%rax)
	movq	-8(%rbp), %rax
	movl	(%rax), %eax
	popq	%rbp
	.cfi_def_cfa 7, 8
	ret

The reference using version performs the same basic logic, but instead of using movl we issue movq, which means our parameters are twice as large. That inefficiency aside we do use an optimization for adding the 1 to our input argument via the leal instruction.

[LLVM]

_Z8test_refRi:
.Leh_func_begin1:
	pushq	%rbp
.Ltmp3:
	movq	%rsp, %rbp
.Ltmp4:
	movq	%rdi, -8(%rbp)
	movq	-8(%rbp), %rdi
	movl	(%rdi), %eax
	addl	$1, %eax
	movl	%eax, (%rdi)
	popq	%rbp
	ret

LLVM’s code is a bit cleaner, focusing on pulling the value from the stack, performing the addl, and retuning the result.

[GCC]

main:
.L5:
	leaq	-8(%rbp), %rax
	movq	%rax, %rdi
	call	_Z8test_refRi
	addl	$1, -4(%rbp)
.L4:
	cmpl	$99999999, -4(%rbp)
	setle	%al
	testb	%al, %al
	jne	.L5
	movl	-8(%rbp), %eax
	movl	%eax, %esi
	movl	$.LC0, %edi
	movl	$0, %eax
	call	printf
	movl	$0, %eax
	leave

As with the function calls I’ve removed the activation record code. LLVM’s main function definition is essentially the same, so we won’t cover it here.

A quick benchmark between the two shows what we would expect from the extra fluff in GCC’s implementation:

GCC
real 0m0.407s
user 0m0.405s
sys 0m0.002s

LLVM
real 0m0.396s
user 0m0.394s
sys 0m0.000s

Level 1 Optimizations

It’s a bit unfair to draw comparisons without some optimizations turned on, so let’s do so now:

g++ main.cpp -O1 -S
clang main.cpp -O1 -S

[GCC]

_Z10test_noRefi:
.LFB19:
	leal	1(%rdi), %eax
	ret

Already we can see a huge difference in GCC’s output, which whittles this call down to a simple Load Effective Address and return.

[LLVM]

_Z10test_noRefi:
	leal	1(%rdi), %eax
	popq	%rbp
	ret

As expected LLVM performs the same lea optimization as GCC.

[GCC]

_Z8test_refRi:
.LFB20:
	movl	(%rdi), %eax
	addl	$1, %eax
	movl	%eax, (%rdi)
	ret

The reference-using version still has to contend with the indirection call via movl ($rdi), %eax, but still a good improvement.

[LLVM]

.Ltmp4:
	movl	(%rdi), %eax
	incl	%eax
	movl	%eax, (%rdi)
	popq	%rbp
	ret

LLVM is using incl to perform our addition call, GCC uses addl. A quick check on Google shows Intel recommends the GCC way.

[GCC]

	movl	$1, 12(%rsp)
	movl	$100000000, %ebx
.L4:
	leaq	12(%rsp), %rdi
	call	_Z8test_refRi
	subl	$1, %ebx
	jne	.L4

The main() function has been reduced to the basics, counting down from our loop initialization value and calling the test_ref() function.

[LLVM]

.Ltmp8:
	movl	$1, -20(%rbp)
	movl	$100000000, %ebx
	leaq	-20(%rbp), %r14
	.align	16, 0x90
.LBB2_1:
	movq	%r14, %rdi
	callq	_Z8test_refRi
	decl	%ebx
	jne	.LBB2_1

LLVM’s main function loop has also been optimized, though again we’re using decl instead of subl.

Although the two compilers perform similar optimizations here, lets examine how LLVM’s structured our reference value for the loop.

Right before the main loop it calls:

leaq    -20(%rbp), %r14

Which maps the address at that base-pointer location to r14. In essence its created an alias. Why it’s done this make sense when we see the rest of the loop.

The first call of every iteration is:

movq	%r14, %rdi

So we pass the address in %r14 to rdi and in the function call we have:

movl    (%rdi), %eax

Which essentially means dereference the value in rdi and push to eax for the incl call. That gets us our added value but it’s the next call where the magic happens, where we tie the whole thing together:

movl    %eax, (%rdi)

Now we’ve moved the value of eax to the address location in rdi. Since that address and the one in %r14 are one in the same, the next call in the main loop to:

movq    %r14, %rdi

Means that his freshly increased value from the function call being pointed to by %r14 is once again pushed to rdi, which in turn is dereferenced in the function call and incremented.

That’s a pretty neat bit of optimization so let’s see how it pans out in terms of performance:

GCC
real 0m0.165s
user 0m0.163s
sys 0m0.001s

LLVM
real 0m0.163s
user 0m0.161s
sys 0m0.001s

It’s much the same, as GCC performs a similar trick using %rdi and the stack.

Level 2 Optimizations

Finally, let’s enable the highest level of optimization:

g++ main.cpp -O2 -S
clang main.cpp -O2 -S

[GCC]

main:
.LFB21:
	.cfi_startproc
	subq	$8, %rsp
	.cfi_def_cfa_offset 16
	movl	$100000001, %esi
	movl	$.LC0, %edi
	xorl	%eax, %eax
	call	printf
	xorl	%eax, %eax
	addq	$8, %rsp
	.cfi_def_cfa_offset 8
	ret
	.cfi_endproc

[LLVM]

.Ltmp7:
	movl	$.L.str, %edi
	movl	$100000001, %esi
	xorb	%al, %al
	callq	printf
	xorl	%eax, %eax
	popq	%rbp
	ret

No need to show anything other than main() because it doesn’t matter.

Both LLVM and GCC have done what we’d expect with such a silly bit of code. Both compilers analyzed the code and came to the same conclusion: the final output value to prinf() can be calculated directly within the compiler, so no need to call anything. Just push 100000001 to %esi for printf() and call it a day : )

In Conclusion

While the code tested was simple, it’s interesting to see how the actual assembly differs. It’s clear that this simple test LLVM produces faster binaries, though not by much.

The other important bit is at least on Fedora, installing and using GCC and LLVM couldn’t be simpler.

Links

Installing and Using LLVM

LLVM Online Compiler Demo

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.

In the previous post we wrote a short C++ program that loaded two numbers. Despite its simplicity in C++, we saw how the assembly version was comprised of several dozen individual instructions in a rather cryptic format. Much of this complexity stems from the fact that in our sample program we called a function to perform our addition. Calling functions means dealing with a stack, base pointers, and the setup and maintenance of that stack. It means dealing with memory offsets, relative positions, and several other factors. The good news is that at this point we can safely ignore these details. In fact, we will do well to ignore them and focus on just the core competencies of function implementation code. In other words, we’ll let gcc create the function shells, calls, and stack management, we’ll focus on the core logic.

The general idea is that we want to write assembly that adds two numbers together. There is a direct assembly instruction for doing so, add, and in this post we’ll implement it.

One of the key things to remember about writing assembly is that we’re dealing with very few abstractions. In C++:

Has a very specific meaning, but its true meaning to the machine it runs on is hidden. It’s only after gcc compiles the code that int, t, and 10 mean anything to the processor. In assembly we free ourselves from these abstractions and deal with the very direct process of moving bits around.

Thus, our first step in writing assembly to add two numbers is to realize that the add instruction we’ll be using expects two parameters, neither of which can be memory locations. They can however, be registers. Thus, our first steps in code must be to load two registers with the values we want to add.

To load a value into a register we use the mov instruction, which for us in AT&T syntax takes the form of:

This moves the immediate value (2) into the %rax register. Please keep in mind %rax is a 64-bit register, it would be %eax on 32-bit systems.

We then push our second number:

And finally, call the add instruction, passing in our two registers:

The whole function in extended assembly looks like:

Should we run this in our IDE, we would watch the rax and rcx register’s end up with 0×1 and 0×3, respectively.

Thing is, this is not a very useful construct, as immediate values means we’ve hard coded the return in by default. It’s much more realistic to accept parameters.

To do so, we take advantage of gcc extended syntax like so:

Will output:

While we now have plenty of control over implementation, it’s still a bit heavy on syntax. Thus, we can further optimize by letting gcc have full control over register assignment:

Here we let gcc decide which registers to use, which leads to slightly faster code generation, but we may lose the exacting control we need.

At this point we now have a functioning addition routine. Of course we already know it’s not the most efficient, as we could/should be using lea. This is because while our actual hand-written assembly is shorter, we still need to place values in registers and use the two-step addition instruction.

The Original ‘Command Line’ Code

We perform a couple of distinct steps in this code. First, we open our directory for iteration with:

And then write the contents of the file into a buffer with:

Not too complicated: We use getline() to only get the raw text of a line, to which we then add a \r\n. We do this because part of our task is to recreate proper tags, and it just so happens that so long as we know where our line breaks are, we can do so reliably. Adding our own line break tags means cross-platform differences will be eliminated, plus our p tag code will run exactly as intended.

The remainder of the code removes extra formatting from headline elements, as well as adds p tags in proper order and sequence. Most of this logic, as it turns out, was the same in Qt, though we did have some significant differences in key locations.

The New Code

The new code segment is the result of a fair bit of experimentation. The command line version was in fact easier to create, though only because of the higher availability of resources for performing file opening, string manipulation, and file writing in plain old C++.

Some key points are as follows:

The method used to iterate through a directory:

…feels a bit strange to me, almost as if I’m missing something. Specifically, the while() statement checks for an empty string if no further files are found. This just seems…wrong to me, but I could be mistaken. For the record, examples given in Qt help documentation had a flaw of never returning the last element of a directory. For example, if we had four items, only three would be iterated through. The do { } while() was the only way I found to hit all files.

As similar as the core logic is, here’s where things take a pretty radical departure from the command line version.

In this code we’re using the handy QTextStream on an address of a QFile object to read each line of text, to which we add the \r\n to, just like the command line version.

We also save a chunk of time here by using REGEX enabled replace method to remove unwanted tags from the headline text:

As you may recall in the old code we used a more complex:

The last part, the section where we add our properly closed p tags, is largely untouched, save for using indexOf() instead of find(), as well as using mid() to build our temporary string for editing.

The last step was to write the fixed file back to the file system. In the first version we used the rather succinct ofstream to do the job, The new version used a more complex series of command as:

Of course we may have a more simplistic way of doing this, but I didn’t find one.

Closing Thoughts

The end result of our project is a slick little Qt desktop app that removed the burden of command line operation for its use. However, as nice as this may be for the end-user, as a developer what I was most curious to see was if Qt would stand up to the challenge of being user friendly, powerful, and at the same time, a joy to work with.

Simple answer: It was. Qt is simply brilliant–I’m sold, hooked, and thoroughly excited to learn and do more with this library. It’s all the power and functionality of C++, but wrapped into a cross platform, easy to use deployment platform with powerful tools and solid documentation.

Though of course this is somewhat relative when it comes to porting command line app to a GUI. Our command line app weighed in at 223 lines, Qt: 368. While it was very easy to find examples of file operation for vanilla C++ on the web, it was markedly more difficult for Qt. In fact, as hinted at in the text I’m still quite unsure of the “properness” of this code. It works well enough, but am I missing something?

Do I really need to used a QTextStream to write data, or should I have used the more low-level write() function inherited from QIODevice? This question reminds me of the difference in PHP between using:

verses using:

In short, one simple step vs. a few more obtuse ones. It’s by no means wrong, but I can’t help but wonder…

Of course it should also be said that this program could use more error and sanity checks if it was to ever be released an a commercial app, but in this case, it’s just for pedagogical purposes.

Complete Application Source Download

Being a Qt app you should be able to run this code (build) on any platform Qt supports.
Download cleaner.zip

The goal during this step is to make exclusive use of the Qt frameworks built-in functions and methods for handling these tasks, as the end result must be a cross-platform compatible app.

We’re already getting a valid directory entry from part 2, so the first step in this part is to figure out how we iterate and query files from our base folder.

As setup for this task, in the first app (the command line one) we defined a few globals:

We’ll keep that basic structure, but of course implement them as member private variables. It should be noted that in the new version the ‘base’ directory value comes from our Worker constructor with:

In the worker constructor we then:

Same thing as the original version really, though one thing I had to check on is if using / will be a problem for Windows. *Turns out the answer is no.*

With the setup tasks done notice that in the GUI we have two buttons: The first allows us to select the base folder, the second kicks off the Process Images task. Notice how we do this: in cleaner.enc__cppqt our clicked() SIGNAL of the processButton button is assigned to the processAction slot, which in turn, after creating our Worker instance object, calls cleanImages(). And so we’re getting an images directory via the GUI–so far so good!

This brings us to the next big question question: how do we open and iterate over directories?

Iterator Over Directories

As you may recall the first task of our program is to remove all files with a _bw_ in the name from the /images sub-folder. It looks like we have: QDirIterator and QDir to help us perform this duty, with the possibly of others as well. The former seems to be for general access, the latter for iterating–we want to iterate.

Basic QDirIterator Implementation

Pretty strait forward really. Iterator over the directory, making sure to skip the path items.

This takes care of the iteration, now we need to find and remove files that have the _bw_.

In the old code we used:

I should step back to mention the first step was to get the file name. In the first attempt we relied on a struct returned by dirent to store file info for checking, now we have a nice simple fileName() method to call. I’m not going to lie, the Qt way feels much cleaner than the command line version. dirent was tricky to work with at first without having a debugger, this is no longer an issue in Qt. With that out of the way, what of finding the text “_bw_”?

I suspected, and was proven right, that QString would have some type of find function. Sure enough:

Beautiful! I can’t help but show my gratitude over such an elegant and natural thing. Without any documentation look up I was able to basically guess and implement my search function in one line. Yes std::string had the same thing with .find(), but this was a nice treat regardless.

Right, so now how do we delete files?

In the first version we had to use a separate variable (location) and a member function .c_str() to pass to the delete(char*) call. This is fine, but a touch verbose. It would be nice to encapsulate this a bit more.

Delete File Implementation

It turns out that we can use the same remove() call, though it wants a char*, we’ve got a QString. As was the goal anyway, we want to use native solutions for cross-platform consistency. I did some digging and found QFile. QFile has a member function for removing files: .remove(). Even better though, QDirIterator has a member function filePath() to return the full path to the file (not just file name). Of course I may have missed similar functionality in the first go (such as using QDir), but now we save ourselves the hassle of rebuilding the file path from scratch. The final code is:

Sure it’s about the same length as the original command line code, if not a bit longer, but it feels more intuitive–almost like OO PHP coding. I do not however, like the idea of creating a new QFile for each item to remove, but I’m learning–I’m sure we’ll find a better way in the next few posts.

Final Method Implementation

For the sake of completeness, here’s the final cleanImages() function:

Up next, rewriting the cleanXMLStoryFiles() function.

The following code will spawn 2 threads (for a total of three program threads), and calculate 40 iterations of the fibonacci_number function. You can make it spawn more threads via threads, as well as change the number of iterations via the iterations < 40 condition.

I also have some test code at the top of our threadfunc method for variable passing. Any time you start working with threads you need to be aware of the pitfalls that come with data access, and this is something I very much look forward to learning more about.

Please note the code was run on Linux, specifically Ubuntu 10.04. You’ll need the g++ compiler and other dev libs via individual packages (e.g. libc6-dev) or <sudo aptitude install build-essential>.

Also, as the in-code comment below states, you need to include the Posix Threads library in the Linker  Properties of the project properties area when using NetBeans, I’m not sure about other IDE’s.