(As I said before, this is a complicated subject.
)
First the obvious:
AH servers do not run a 64 bit operating system. Currently the only fully 64 bit operating system available for the Opteron is Linux. AH's servers do not run Linux. Hence the Opteron would operate only using standard x86 instructions (i.e. 32 bit). Thus any performance advantage seen moving to an Opteron based system with regards to AH would result from the other architectural improvements I mentioned.
Now for the not so obvious, and there are a lot of things I could type here: (
)
1. A 64 bit ALU or FPU design is going to be inherently SLOWER (on a maximum clock rate basis) than a 32 bit unit of any practical design. If you want to know why you need to look at how a carry lookahead, carry save, or carry propagate adder is constructed. The number of additional gates required for each successive bit beyond a point becomes very large. (This is the reason why the P4 uses 2 16 bit units within it's ALU clocked at 2x core frequency.)
2. The effective size of your data caches is essentially halved when moving to 64 bit operands. This reduces the chances for a cache hit and results in more accesses to main memory, reducing performance. (This is the reason why the Hammer core has larger caches and an integrated memory controller on die.) Another thing to consider is that each operand being 64 bits long instead of 32 bits means that a program will consume much more system memory, and as a result with all things being constant (i.e. no increase in system ram) the hard drive will be accessed more often, reducing system performance.
3. What qts describes in his post can be visualized in two ways. It makes the assumption (correctly by the way
) that simply combining 2 32 bit operands into one 64 bit operand and performing a single instruction on it results in better performance. That is in fact generally true, and what that is known as in a broad sense is "SIMD" instructions (Single instruction-multiple data). This is in fact the type of instructions in the Intel/AMD SSE, SSE2, and 3dNow! instruction sets. (The Opteron and Athlon 64 add support for SSE2 instructions.) These instructions essentially perform the same operation on mulitple operands at the same time, improving performance. Now here's the problem: To take advantage of this a program would need to be rewritten to include such instructons or at the very least recompiled with a very "smart" compiler (an oxymoron for sure
). Running existing code on the Opteron results in no performance advantage just because it's run on a 64 bit processor. The performance boost seen versus other processor designs is because of other design improvements, as I mentioned previously. I think that's what Gatr was asking...
4. Distance, trajectory, and the like will not be computed faster on a 64 bit processor just because it is "64 bit."
When talking about graphical realism because of the processor being 64 bit, I'm not sure how that is by any means obvious. Simply moving to a 64 bit processor from a 32 bit one will not result in more realistic graphics by itself. From a gaming standpoint the video card has much more impact on graphical realism than the processor.
I guess to answer the question posed at the start of this thread I should say that the server running on a 64 bit platform versus a 32 bit one will do nothing to improve the gaming experience. That's not saying that the Opteron is not a good processor, on the contrary, it is certainly quite superior to the current Athlon MP and Intel P4 Xeon processors. It's architecture is VERY well suited to a multiprocessor design and is very well suited for use as a server processor. Taken from that standpoint, a faster server is always a good thing from a gaming standpoint.
The problem with debating a subject such as this is that there is really no right answer...
