My kid hates Linux (ZDNet)

There are major differences with x86_64 that show up everywhere, not just for math.  The
calling convention on the 64-bit system are far cleaner.  More arguments can be passed to
functions in the registers (6, I think) than on 32-bit systems, where the extra arguments have
to be placed on the stack.  Stack management function on x86 are not free; they take one or a
few cycles during every function call and function return.  This can add up.

x86_64 also allows more and better ways of addressing data that can save an explicit load to
register.

These are not theoretical improvements.  Lots of programs run much better on x86_64 than on
plain old x86.

The 64-bit systems do still have the problem of larger pointers which can crowd the cache, but
some programmers find ways around this.  BEA, for example, uses short heap pointers in their
JVM, which gives them all the speedups of the x86_64 programming model (described above)
without paying the cost of 64-bit pointers.

Counterpoint, RAM is pretty cheap these days. Just Add More.

Of course, you do come across motherboard limitations occasionally.

If 64 bit pointers are really that big a deal, how come the EDA guys don't use 4GB memory
pools with 32-bit offsets?  That's way you get the speed and huge memory space of 64 bits with
the space efficiency of 32 bit.  Seems like a win-win.

It's been quite a while since I've done EDA (some VLSI layout and simulation back in 2003).  I
remember some seriously crufty software produced by vendors who would do anything to avoid an
update.  Some of the tools I used were written *and compiled* pre-1998!  It was a nightmare
trying to get that junk to run.  I eventually got the toolchain working and then I never let
anybody touch that box again.  Not so much as a security update or a package upgrade lest it
break anything.

So...  If the EDA industry is indeed pushing back against 64 bit, there might be more to it
than just pointer size inflating the working set.  :)

Fair enough; your particular daily-use EDA app (proprietary?  you've never actually mentioned
what it is) performs worse.  You use what best supports your needs, after all.

However, my daily-use apps perform significantly better under 64-bit.  That 11% improvement
with dcraw was the only one I could recreate the benchmarks on immediately, as it's trivial to
recompile.

My main daily use app (GCC cross-compiler building a multi-million line codebase) runs
considerably faster under x86_64.  However, I no longer have an identical 32-bit system for
comparison any longer, so I can't supply benchmarks without blowing half a day on it.  (The
64-bit gnome desktop *feels* faster too, but that's obviously subjective)

One of the folks I work with has also raved about the improvements he saw using the 64-bit
versions of the particular FPGA synthesizer tools.  

Not to mention the speedup one gets by not needing bounce buffers (and other games) for I/O.

I suppose it's true that if you use an artificial 2.5 GB dataset and impose a 2 GB memory
limit, 32 bit would be faster.

In the real world, why wouldn't you just spend $50 for a 2GB memory upgrade?  Then the 64 bit
box would fly.  If you're not convinced, let's try this exercise again with a hypothetical 3.2
GB data set.  :)

In my experience, modern 64 bit boxes with stuffed with lots of ram are really cheap and
really damn fast.  I can't think of any reason to deploy 32 bit for servers/HPC these days.

That's very interesting.  Has anybody tried working around this?

One solution would be convert hot 64-bit ptr fields to 32-bit offsets pointing into a single
memory pool.  I'm not familiar enough with the networking code to know how traumatic this
would be.  (I'm definitely not saying do this everywhere; just where it really matters).

This topic might make a fairly fascinating paper.  :)