C and C++ code is often written with an architecture in mind.

Typical 32 bit x86 C and C++ code had various bugs, especially around the assumption that ints and pointers are the same size, that needed to be fixed after recompiling for 64 bit (and discovering things didn't work).

But that code also has a lot of flaws from its x86 origin that led only to performance problems in 64 bit, not outright bugs. Most of that hasn't been fixed, and that is one reason x86-64 programs may be slower than the same programs in 32 bit x86.

One common error is the use of the long data type for values that ought to be 32 bit. Too many x86 programmers remembered the ancient history of C, when long was likely to be 32 bit and int smaller. So values that ought to be 32 bit regardless of architecture were often coded as long. In x86-64 most of those misuses of long work (but slower) so they were not serious enough to get corrected.

There may be even bigger differences from no longer correct decisions about which resources matter: Long before 4GB was a reasonable amount of ram, the 4GB limit on virtual address space was a significant limit. There are many programming situations in which extravagant use of sparse virtual address space (with neither physical ram nor even swap space backing it) can simplify and speed up programs. But programmers rarely made use of such designs because the 4GB limit didn't give enough headroom above ordinary use of virtual memory to allow extravagant uses of address space.

The 47 bit (user space) addressing limit of x86-64 jumps far enough beyond currently reasonable levels of virtual memory, that many of those extravagant uses of address space would be very practical and could simplify and speed up programs. But only if those programs were designed for x86-64. Simply porting / recompiling programs for 64 bit doesn't provide any of those improvements.

The big improvements from just recompiling for x86-64 are in two areas:
1) All x86-64 CPU models have SSE floating point as well as legacy floating point. SSE floating point is easier for the compiler to use for good binary code, so that is what the compiler uses. Most x86 CPUs also have both kinds of floating point, but some only have legacy, so the compiler uses legacy floating point for 32 bit programs in order to eliminate complications from keeping track of which model of x86 CPU can run the code.
2) 64 bit mode supports twice as many registers. The design of GCC is too architecture independent to deal well with the shortage of registers in 32 bit x86. So the binary code is often poorly optimized where the compiler trips over the lack of registers (old versions of Intel ICC for 32 bit x86 do a much better job dealing with the register shortage).

Those big improvements are balanced against the big disadvantage of 64 bit mode. On the same model CPU, 32 bit mode and 64 bit mode run with the same size L1 and L2 cache. But many programs internally use a LOT of pointers. Pointers are twice as big in 64 bit mode. So the 64-bit pointers crowd each other and other things out of cache, making more cache misses and slower program execution.

The net is usually no big difference in performance. There are a few programs that get unusually big boosts from SSE and/or double the register count overwhelming the extra cache misses from pointer size and thus running a lot faster in 64 bit mode. But for most programs the performance factors balance to no significant difference.

In theory, a word processor or web browser or spreadsheet or database etc. would be internally coded in a way that is quite heavy in its use of pointers and thus increased cache misses should balance SSE and double register count, resulting in no performance difference.

In theory, data compression or decompression or transcoding or resampling video (changing the format or resolution etc. of video) should get a big boost from SSE and should use a large fraction data whose size is architecture independent and small fraction pointers that are bigger in 64 bits (compared to other tasks, relatively few pointers are used a lot and it is storing the pointers, not actually using them that has the performance issues). So those tasks ought to see bigger performance gains from x86-64 and some people testing such tasks claim to see those gains (I haven't seen tests I consider controlled enough to be really convincing).

But until you see profiling results, there is a big gap between what any theory says about performance and what is really happening. So I don't think it is safe to predict the size of the performance gain even based on the application type. Internal details of the coding style in a specific application may matter a lot more than the overall class of application.

1 members found this post helpful.

@johnsfine

Wow. I like how your long posts almost always seem to be educational. Thanks.