[geeks] 64-bit apps vs. 32-bit apps

[Jonathan C. Patschke]

On Fri, 29 Dec 2006, Ido Dubrawsky wrote:

> Can anyone out there answer whether it's better to use a 32-bit app on
> a 64-bit machine or a 64-bit app?  I've read an article that said that
> MySQL performance as a 64-bit app is actually worse than the 32-bit
> version.  Any thoughts?

A lot of it is application-specific.  There's the immediate negative
trade-off of a typically larger memory footprint (due to more stringent
alignment requirements and instructions that are, themselves, possibly
twice as large), but there's the immediate positive benefit of
potentially better instructions, but this only applies if your compiler
supports your CPU very well and the application you're building (or the
libraries it uses) uses code that lends itself towards expression with
these better instructions.

In addition, if your application is actually using pointers, integers,
or floating point numbers that will benefit from the larger address
space and register size, you get that benefit from a 64-bit executable,
as well.  That MySQL, an application which should run -faster- with
64-bit ints and a nearly boundless address space at its disposal,
actually -slows down- in 64-bit mode should speak volumes for the
quality of code churned out by that development team.

On i386 vs. amd64, there's also the notion of compiling 64-bit to get
something approaching a reasonable number of general-purpose registers,
which can speed up nearly any program.

However, on SPARC (and on MIPS[0]), you can get 32-bit versions of most
of the enhanced instructions without compiling for a 64-bit target.
With Sun C, you want to pass this:

    -xtarget=ultra2 -xarch=v8plusa

Really, the only way to determine what makes your application run the
best is through testing.  At a minimum, you'd want to build versions
with:

    * Compiler defaults (for a baseline)
    * 32-bit optimised for your processor
    * 64-bit baseline
    * 64-bit optimised for your processor

Then, it's up to you to determine a decent benchmark.  I found, for
example, that whatever version of gzip I was running at the time
performed the same whether built n32 or n64 on my Octane, but was
significantly faster built -xarch=v9 -xtarget=ultra on my Ultra 1e than
with the compiler defaults.  Alternatively, PostgreSQL was a whole HELL
of a lot faster built n64 versus n32 on the Octane, but was about the
same either way on the Sun.

There are, of course, two very sad caveats to all this:

   1) For a single system, any consistent performance benefit is likely
      not worth the time and effort it took for you to provably show
      which compiler flags did it.
   2) Modern-day software is so obese, wasteful, slow, horrible, nasty,
      intertwined, and altogether bletcherous that an inefficient
      compiliation should be the least of your concerns regarding
      performance.

That said, I went through the trouble of building the whole world 64-bit
the last time I redid my Solaris environment, and I'm not displeased
with the results.  YMMV.


[0] In fact, in MIPS land, you can get 64-bit integers without 64-bit
     pointers, which lets you have most of the benefits of a 64-bit
     system on a kernel and system that don't support full 64-bit mode.
     MIPSpro and IRIX refer to this as 'n32' mode. 'o32' is straight
     32-bit mode.  'n64' is straight 64-bit mode.
-- 
Jonathan Patschke  ) "Some people grow out of the petty theft of
Elgin, TX         (   childhood.  Others grow up to be CEOs and
USA                )  politicians."              --Forrest Black