posted by Tony Bourke on Thu 22nd Jan 2004 21:29 UTC

"Benchmark: 64bit vs 32bit, Page 3"

MySQL 4.0.17

MySQL was the most challenging, as compilation is quite a bit more involved than either gzip or OpenSSL. I ran into several problems getting it compiled for 64-bit, but I was able to sort them out and ended up with a 64-bit binary. The added “-mcpu=ultrasparc” for the compile flags (for both the C compiler and the C++ compiler, MySQL uses both), and of course “-m64” for the 64-bit version. The MySQL configure script added “-O3” as a compiler option.

To test MySQL, I used the included sql-bench, which is a benchmarking toolkit for MySQL and a few other RDBMs. It consists of a Perl script runs that through a set of operations using the DBI and DBD::mysql Perl modules. On this system, the full tests take about 4 hours to run, so I only ran the tests twice, and took the best of the two. There was very little disparity between the tests.

It should be noted that for both the 64-bit and 32-bit tests, I used the 32-bit build of sql-bench and MySQL client libraries, as the Perl I used (5.8.2) is 32-bit. This was done to keep the client end consistent. To complete each run takes about 4 hours, so I only ran them twice, and used the best run. Again, there was little disparity between each run.


MySQL:32-bit versus 64-bit (shorter is better)


MySQL:32-bit versus 64-bit (shorter is better)

The MySQL results were a bit surprising, as two of the operations, insert and select, showed faster results for the 64-bit binary of the MySQL server than the 32-bit version.

The Size Factor

Another argument against 64-bit binaries that I see frequently is their larger size. And indeed, all of the 64-bit binaries and libraries created for this test were larger:


Binary

32-bit size (bytes)

64-bit size (bytes)

% Larger

mysqld

3,993,792

4,864,832

22%

gzip

75,472

115,976

54%

openssl (shared)

465,256

539,992

16%

openssl (static)

1,568,640

1,935,736

23%


Library

32-bit size (bytes)

64-bit size(bytes)

% Larger

libcrypto.so.0.9.7

1,404,964

1,733,864

24%

libssl.so.0.9.7

244,280

294,056

20%

However, the difference wasn't all that huge, only around 16% to 54% larger for 64-bit than 32-bit. Unless the system was an embedded system with very limited storage space, I can't see this being all that much of a negative factor.

The Compile Factor

Getting applications to compile as 64-bit binaries can be tricky. The build process for some applications, such as OpenSSL, have 64-bit specifically in mind, and require nothing fancy. Others, like MySQL and especially PostgreSQL (I was originally going to include PostgreSQL benchmarks) took quite a bit of tweaking. There are compiler flags, linker flags, and you'll likely end up in a position where you need to know your way around a Makefile.

Also, building a 64-bit capable compiler can be an experience to behold. That is to say, it can suck royally. After spending quite a bit of time getting a 64-bit compiler built for (one of my many) Linux installs, I ended up just going with the pre-compiled version from http://www.sunfreeware.com.

Both compiling a 64-bit capable compiler or getting an application to compile 64-bit can be time intensive, as a compile will often start out fine, and die somewhere down the line. Then you fix a problem, start the compile again, and it will die maybe 10 minutes later. Then you'll fix another issue, and repeat until (hopefully) the compile finishes cleanly.

The Library Factor

One important factor in considering whether to compile/use 64-bit binaries is the problem of shared libraries. Initially, I hadn't even thought of the library issue, but when building 64-bit applications, I came to find it was significant.

The issue is when using a 64-bit application that's requires external libraries, those libraries need to be 64-bit; 32-bit libraries won't work.

Take OpenSSH for example. It's typically dynamically linked, and requires libcrypto.so. If your libcrypto.so is compiled 32-bit and SSH is compiled for 64-bit, you'll get an error:

> /usr/local/bin/ssh

ld.so.1: /usr/local/bin/ssh: fatal: /usr/local/ssl/lib/libcrypto.so.0.9.7: wrong ELF class: ELFCLASS32

Killed


This means you may very well need to keep two copies of your shared libraries: One set for 32-bit binaries, and another for 64-bit binaries. Solaris keeps 64-bit libraries for in directories like /usr/lib/sparcv9. You'll also need to adjust your LD_LIBRARY_PATH environment variable to point to where these 64-bit libraries are located when running a 64-bit binary.


I ran into this time and time again throughout these tests and throughout the entire evaluation as a whole, and it was a huge pain in the ass.

Conclusion

While these tests are limited in scope, and there are far more sophisticated tests that could be performed (such as raw integer and floating point), this is a start, as I haven't seen any 32-bit versus 64-bit tests out there. The lack of other benchmarks seems strange to me; perhaps I didn't look in the right places. (If you know of any published benchmarks comparing 32-bit binary performance versus 64-bit, please let me know).

Keep in mind these tests were performed on the UltraSPARC platform for Solaris 9, and while they probably would have relevance to other operating systems and platforms (such as Linux on x86-64, or FreeBSD on UltraSPARC), specific tests on those platforms would be far more revealing.

So while the tests I ran were on only a few applications and in limited ways, the results seem to show that indeed 64-bits do generally run slower. However, there are there are a few issues to consider.

One issue is that the difference in performance varies not only from application to application, but also what specific operation a given application is performing. Also, the largest disparity I was able to see was around 20%, and not the many-times-slower disparity that I've seen some claim.

Since this was a limited number of applications in limited scenarios, the best way to know for yourself is to give the applications you're concerned about a try in both modes.

In the end it's the library and compiling issues that are the most compelling reasons to stay with 32-bit binaries, and not so much performance or size. I think it's safe to say that you're not missing out by going with the simpler-to-manage 32-bit binaries, unless your application can specifically benefit from 64-bit.

Related reading: My Sun Ultra 5 And Me: A Geek Odyssey

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