64-bit computing Saturday, 25 March 2006  
I recently managed to purchase an old Sun Ultra 10, and managed to install Solaris 10 on it (cost: 65 GBP)

Its a few years old now but better than my old UltraSparc-1 (new machine runs at 440MHz vs 170MHz for the old machine).

At last I get to try out Solaris 10 and dtrace, but first...

Was deciding what to do with the box - its kind of a spare, or maybe its time to upgrade CRiSP from a Solaris 2.6 build to a Solaris 10 build. If we support the later build then it means people on older Solaris versions wont be able to run the binary, so thats an extra release to support for no reason.

Anyway, decided I could finally build a 32-bit and 64-bit build of CRiSP on the same machine, and see what the relative speed up/down would be for identical software running a performance test.

Result: 64-bit about 10-15% slower than the 32-bit one.

I was semi surprised with this, but the figure agrees with values banded around everywhere. Theres more code to execute, bigger cache footprint, and few areas where the 64-bit wins against the 32-bit code. So its debatable whether one wants a pure 64-bit system and tools.

The interesting bit is that at this point in time, with 64-bit Intel and AMD chips becoming the norm, and dual cores becoming ever more the standard, it implies what will happen in the Windows/Linux space.

A dual core chip tends to run slightly slower than a single core (due to heat and power issues). So a 64-bit dual chip, running 64-bit native software is going to run even slower still, so the implication is that a "bang upto date" Intel/AMD box could be as much as 30% slower than a pure 32-bit single core processor.

Posted at 09:55:43 by Paul Fox | Permalink