Cocoa Geek


LLVM-GCC benchmarks

Posted in General Development by andrew on the August 3rd, 2008

Over the weekend i compiled LLVM and the LLVM-GCC front-end on ubuntu mostly because of all the hype surrounding it at the moment. Alot of people are talking about the optimization improvements over GCC and the increase in performance it give - if all the hype is to be believed no one would be using GCC anymore. So what is the state of play with it at the moment?

Well its biggest breakthrough up until now has been its inclusion with OS X with xCode 3.1. Although not currently the default compiler it is still there and there has been alot of talk about it being shifted to the default compiler in the near future. I imagine this would happen as apple have been funding alot of the development of LLVM themselves, they seem to view it as being one of the parts that will dramatically increase performance in the future on OS X particularly in regard to the multi-threading advancements in Snow Leopard.

In the Ubuntu / Debian world there isn’t quite as much support yet for the compiler, trying the packaged off the Ubuntu repositories is a waste of time at the moment, they are badly packaged, badly named and to be honest don’t work out of the box. Reading the mailing lists would give us the picture that there is a large effort to put these into the upstreams for the next Ubuntu release (Intrepid). So i compiled them from the sources, one important thing to point out that is not in the documentation for those who do want to compile them on linux is that they require the gperf package - and won’t give you an error until it is too late, i ended up starting the whole thing again. Other than that compilation is nice and easy.

So how about performance? Well first of all i tried re-compiling some of my favorite apps with the LLVM-GCC compiler and i didn’t get one error. Adding the -Wall flag however did miss some warnings out that are flagged up by GCC.  Compile times seemed generally quicker however i didn’t actually do any measurements for this yet.

Execution performance was something else i tried to measure, i got hold of  a very CPU intensive calculation off a friend and compiled it with both GCC and LLVM-GCC, the GCC execution time in 3 runs all averaged out to 55s with a SD of > 0.02 of a second. Running the same calculation compiled from LLVM-GCC gave a mean execution time of 38 seconds with the same SD - thats a saving of 30% in this example.

The code i was running for this test is typical scientific number crunching with 64bit ints, so this is obviously a very useful advantage and time saver on a calculation that would take longer to run.

The next thing i tried was running the amber granular synth, again this was compiled with both of the compilers and again i ran each execution 3 times. I chose one of the example run’s from the documentation the only change being i increased the size of the output file from 5s to 60s. Again there was a quicker performance with the LLVM-GCC compiler although this time not quite as impressive. The mean for the GCC compiled version was 1.433s, the mean for the LLVM-GCC version was 1.186s. This is a time saving of roughly 20%.

These results obviously show that LLVM-GCC does live upto some of its hype, however it will be interesting to see what the state of play is like in a couple of years. Will it still be being talked about in the same way? Or will the GCC guys improve their optimization techniques in future versions? I am still interested in testing it in other ways as well, these tests were both CPU intensive but not really data intensive. That will be the next set of tests that i will try.

Slightly esoteric jam session

Posted in Uncategorized by andrew on the August 1st, 2008

Well on monday night a regular band practice managed to turn into an electronic jam session, which we took some live recordings of. These are avalible for listening pleasure on music.cocoageek.com. These are performances by myself and richhoo.