Generally i think as a web-server it is easier to set-up and configure than apache - setting up an RRD perl script to log my RAM and CPU usage was a dodle as was all the fastCGI stuff. I’ve not yet tried to do anything too fancy like serving a ROR app or a JAVA app or anything like that, although now i have the RAM to spare i might have to give it a go…

sudo update-manager -d

The installation is remarkably quick, installing all the updated packages. The only problem i had with the installation was my GRUB config file was overwritten meaning i had to re-write some entries. As with previous upgrades config file diffs can be displayed and merged as required.

After a quick restart and reconfiguring my display drivers (very easy - just a matter of picking the correct driver) i was in 8.10. Changing my theme and background to the new artwork i was very pleased to see the removal of that awful orange that has been used in previous versions, its now quite a nice dark and moody brown which reminds me somewhat of Ubuntu Studio.

On the whole it has been remarkably stable, since the feature freeze is coming in now then future updates are going to be entirely focused on fixing bugs. I am currently running the update commands about twice a day and getting at least 15 packages updated each time.

I can’t wait until it is fully stable and released at the end of this month, Ubuntu is getting stronger and stronger as a desktop OS and with the current 6 monthly release cycle its also moving very quickly. I think a huge amount of credit should go to the community for working so hard on bug fixing and packaging. Making this OS the easiest linux distro to get started with.

A Segmentation Fault is a fault that is given when a program tries to use memory to which it does not have permission either by trying to read or write to it… Basically it is a total pain in the ass… Debugging these types of problems can be tricky.

Using C one of the most common, and first found causes of this is with the scanf() function. For instace compiling the following code will read a number from the standard input and write it back out:

#include <stdio.h>

int main(void) {
  int n;
  while (scanf("%d", &n) == 1){
    printf ("%d\n", n);
  }
  return 0;
}

Running this should work fine, now lets try editing this code and instead of passing &n (the pointer) as an option to scanf() lets just pass the int n:

#include <stdio.h>

int main(void) {
  int n;
  while (scanf("%d", n) == 1)
    printf ("%d\n", n);
  return 0;
}

Running this will give us a segmentation fault. This in a large program can be insanely difficult to debug as your pointer could be defined a long time before it has been called to a function. So how can you start to debug this?

Well the tool i used for the first time was truss (the linux version being strace, and the osx version being dtrace) what this does is allow you to view as system calls a process makes as it is being called - or at what system call it crashes on. In other words if you are trying to open a file or read a memory address that can’t be called you will see it here:

read(0, "1\n", 1024)                    = 2

--- SIGSEGV (Segmentation fault) @ 0 (0) ---

+++ killed by SIGSEGV +++

Here is the final lines of output after running the strace command on my faulty scanf() code. It shows clearly that my program dies as i try to read the line from the standard input. The other important thing is that i didn’t have to recompile my code with a debugging flag to try to work out where my bug was. Strace (etc) reads the system calls - therefore telling you when and where you read memory or files, remember here that unix assumes they are essentially the same thing.

There is a huge amount of these programs that i haven’t talked about here - it is a very simple use of the command however one i wanted to document (as much for my own reference in the future as much as for anyone else!) because it is an essential command for trying to figure out why a program is dying, you don’t even need the source code in order to do this kind of debugging. I think its also important to be aware that this tool can also be used for ensuring your code is secure, integer wrapping or other similar vulnerabilities can be assessed using tools like this.

I do however find it very interesting that they have chosen to use webkit as the back end for the browser as opposed to gecko. Google has long funded mozilla and therefore the gecko platform, webkit however was a fork of the knoqueror browsers KHTML by apple. Apple prefers open source projects it works on and with to be under a BSD style license in order that the code can be used in close source applications, this is a possibility for using webkit over gecko.

Ultimately googles choice of rendering engine has little impact on the success of their browser, the usability and compliance with the web-applicatios that people use will be far and away more important in the success or faliure of Chrome.

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.