Author: Matt Taylor
Date: 00:10:46 02/07/03
Go up one level in this thread
On February 06, 2003 at 00:29:46, Russell Reagan wrote: >A few questions about 64-bit machines... > >1. For chess programming (mainly for bitboards), do either AMD or Intel's 64-bit >chips have any features that would make it more desirable over the other? Number >of registers, cache size, special instructions (bsf, popcnt, etc.), or whatever >else. Bitboards will benefit from the 64-bit word size in either case. The IA-64 is designed to issue 6 instructions per clock to up to 10 (IIRC) execution units. The x86-64 is just another Athlon (but 64-bit), so it can issue up to 3 instructions per clock to up to 9 execution units. There is another subtle difference, too; IA-64 is heavily optimized in software whereas IA-32 is heavily optimized in hardware. In IA-64 it is possible to achieve rates closer to the theoretical 6 instructions per clock than it is on IA-32. This is balanced out by the fact that IA-64 runs up to about 1 GHz now. The Athlon64 will run over twice that frequency. The IA-64 is probably extremely nice to compute with (6 MB L2 cache!!) if you have the money. Since I don't, I will pass on making further comparison. >2. How much will one be able to take advantage of the hardware using a C/C++ >compiler and no assembly programming? The reason I ask this question is because >Gerd has mentioned that there will be so many general purpose registers, so many >MMX registers, and so many XMM registers. On 32-bit hardware you have to use >assembly to make use of some of these extras. What about on the 64-bit hardware? >That is a lot of registers (compared to 32-bit x86), and that would seem like an >awful waste if the compilers couldn't make use of all of those extra registers. Compilers will have no trouble utilizing the extra integer registers. I have heard vague whispers of compilers that support vectorization. I've never seen anything real. I don't think MS VC and Intel C compilers can perform automatic optimization yet. Intel tries to mitigate that by offering a library of intrinsic functions. They work just like sin/cos/etc. out of math.h -- the function gets optimized to 1 instruction (because it represents 1 instruction). >3. What is the difference between general purpose registers, MMX registers, and >XMM registers? There are 5 sets of application instructions in the x86: 1. Integer/General-purpose 2. Floating-point 3. MMX 4. 3DNow! 5. SSE 1 - Integer/GP instructions support flow control (branching, functions, etc.), stack operations, arithmatic operations, etc. They operate on the GPRs. 2 - Floating-point instructions obviously do floating-point calculations and use the FP registers. 3 - MMX instructions use MMX registers (mm0-mm7) which are aliased over the FP registers. They support arithmatic & logical operations on 64-bits of data. Arithmatic (add, sub, mul, etc.) can be done in 8-bits, 16-bits, or 32-bits -- multiply can only be signed and 16-bits. Extensions in processors with SSE 2 also allow some 64-bit arithmetic with MMX registers and 32-bit unsigned/signed multiplies. 4 - 3DNow! instructions use the MMX registers, but they do FP computations. AMD also includes a few extra MMX instructions which can at times be handy. 5 - SSE instructions are the end-all-be-all of IA-32 SIMD processing. They operate on the SSE registers (xmm0-xmm7) which are 128-bits wide. Originally SSE only operated on floating-point data, but SSE 2 extensions allow it to do arithmatic & logical computations as well. Also, SSE 2 makes it possible to shuffle data between MMX & SSE registers. Athlon64 will support all of these instructions. Yes, it is a waste when significant portions of the CPU core are dedicated to MMX/SSE and no compiler can generate MMX/SSE code, but an astute assembly programmer can write code for MMX/SSE. Usually hotspots in an application will be targetted and converted to SIMD (MMX/3DNow/SSE) code. -Matt
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.