posted by Tony Bourke on Thu 22nd Jan 2004 21:29 UTC
IconWhen running tests, installing operating systems, and compiling software for my Ultra 5, I came to the stunning realization that hey, this system is 64-bit, and all of the operating systems I installed on this Ultra 5 (can) run in 64-bit mode.

I wondered if it would be best to compile my applications in 32-bit mode or 64-bit mode. The modern dogma is that 32-bit applications are faster, and that 64-bit imposes a performance penalty. Time and time again I found people making the assertion that 64-bit binaries were slower, but I found no benchmarks to back that up. It seemed it could be another case of rumor taken as fact.

So I decided to run a few of my own tests to see if indeed 64-bit binaries ran slower than 32-bit binaries, and what the actual performance disparity would ultimately be.

Why 64-bit?

In the process of this evaluation, I came to ask myself: Why go through all the trouble to make it 64-bit anyway? Other than sex appeal, what other reasons are there for 64-bit?

Checking out Sun's Docs site, I ran across this article: Solaris 64-bit Developer's Guide ( It gives some good detail on when 64-bit might make sense, and is relevant for Solaris as well as other 64-bit capable operating systems.

The benefits for 64-bit seem to be primarily mathematical (being able to natively deal with much larger integers) and for memory usage, as a 64-bit application can grow well beyond 2 GB.

Operating systems seem to be benefiting from 64-bit first, allowing them to natively handle greater large amounts of RAM (some operating systems such as Windows and Linux have ways around the 2/4 GB limit on 32-bit systems, but there is funkyness involved).  There aren't many applications that use more than 2 GB of memory and greater, but there are more on the horizon.

Given that this Ultra 5 cannot hold more than 512 MB of RAM (it's got 256 MB in it now), there's not much benefit in the memory area, for either the OS or applications. Still, I want to see what issues and performance penalties there may be with 64-bit binaries, so I'll give it a shot anyway.

Here are some links for further reading on 64-bit computing.


The first step was to select some applications to run these tests against. They would have to be open source so I could compile them in 32-bit and 64-bit versions, and there would need to be some way to benchmark those applications. I would also need to be able to get them to compile in 64-bit mode, which can be tricky. I tried a few different applications, and ended up settling on GNU gzip, OpenSSL, and MySQL.

Test System

My test system is my old Sun Ultra 5 workstation, for the specs please refer to the intro article. The operating system install is Solaris 9, SPARC edition, 12/03. The 9_Recommended public patch cluster was also installed.

For the compiler, I used GCC 3.3 .2 that I got from which is built for producing both 32-bit and 64-bit binaries. To see if it can successfully produce 64-bit as well as 32-bit binaries, I'll run a very simple test of the compiler.

I create a very simple C file, which I call hello.c:


I'll just run a quick test to see if it compiles in regular 32-bit mode:

gcc hello.c -o hello32

The complier gives no errors, and we see that a binary has been created:

-rwxr-xr-x 1 tony tony 6604 Jan 6 13:24 hello32*

Just to make sure, we'll use the file utility to see what type of binary it is:

# file hello32

hello32: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped

So the file is 32-bit, and runs SPARC Version 1, which means it should run on any SPARC system. And of course, we'll run it to see that it runs correctly:

# ./hello32


All is well, so now let's try compiling hello.c as a 64-bit binary. For GCC, to create a 64-bit binary, the CFLAG is -m64.

gcc hello.c -o hello64 -m64

No errors were given, and we see that a binary has been crated:

-rwxr-xr-x 1 tony tony 9080 Jan 6 13:24 hello64*

But is it a 64-bit binary? The file utility will know.

hello64: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped

The binary is 64-bit, as well as SPARCV9, which means it will only run on SPARC Version 9 64-bit CPUs (UltraSPARCs). So now we've got a 64-bit binary, but does it run?

# ./hello64


OK, so now we're set. Now we can test to see if 64-bit binaries are really slower, but we'll have to use something a little more intensive than “Hello!”.

Table of contents
  1. "Benchmark: 64bit vs 32bit, Page 1"
  2. "Benchmark: 64bit vs 32bit, Page 2"
  3. "Benchmark: 64bit vs 32bit, Page 3"
  4. "A note on Benchmarking in general"
e p (0)    70 Comment(s)

Technology White Papers

See More