Author: Gerd Isenberg
Date: 02:19:03 04/30/05
Go up one level in this thread
On April 30, 2005 at 00:57:42, Steven Edwards wrote: >Moving a program from a 32 bit system to a 64 bit system does not by itself >guarantee a speed up: > >1. If all pointers move from 32 to 64 bits, there may actually be a slow down >due to possibly increased memory traffic. I would assume that the 64 bit >programming model will be 32 bit pointers with a combination of 32 bit and 64 >bit integers. Similar for x86-32 versus x86-64. Pointers are 64 bit - so saving/restoring pointers to memory requires double space. Due to the implicit zero extension of 64-bit registers as operands of 32-bit operations, UInt32 is faster than Int32 as index variable for x86-64, because Int32 requires an explicit sign extension to 64 bit. > >2. In general, using 64 bit values instead of two 32 bit values will halve the >register allocation requirement. > >3. All bitboard operations will speed up by a factor of two (at least). Some >minor low level re-coding may be needed to help with this. hmm... not sure about that for x86-64. A pair of 32-bit instructions may processed in "parallel", while a single 64 bit instruction has higher probability to stall. Also, on x86-64 64-bit operations require an aditionl prefix byte (same for using the new r8-r15 registers). So you have often three opcode bytes versus 2*two opcode bytes. > >4. Bitboard operations that require 64 bit shifts or rotations will speed up by >(roughly) a factor of four. On x86-64 that may be true for variable shifts. Constant 64-shifts for instance to get pawn attacks, are not that bad with two (dependent) x86-32 instructions. > >5. Arithmetic operations on 64 bit integers will likely see a speed doubling for >add/subtract and a quadrupling for multiply/divide. For 64-bit multiply/divide even more than doubling the speed, for add/sub most likely less than doubling (similar to constant shifts, a bit worse than two independent 32-bitwise operations). > >6. For the assembly language diehard bitboard programmers with a PowerPC system, >it would be possible to reserve, say, about half of the 32 general purpose 64 >bit registers for holding the most frequently accessed bitboard values of the >current position. (Eg., Occupied, Sweeper, ColorLoc[2], AttackByColor[2], >PieceLoc[2][6].) It might be worth the attempt if one thinks he can beat the >optimizer at its own game. > What about altivec registers? With my intended bitboard design using fill routines for attack generation, it might be smarter to process as much fill directions as possible "in parallel" inside registers and to store mentioned values in memory. >-------- > >From the start, Symbolic was targeted towards 64 bit systems: the toolkit uses >bitboards very extensively, there are numerous 64 bit counters, and every >integer and floating point value in the ChessLisp interpreter is 64 bits long. >I'm expecting a significant speed up, but actual figures will have to wait until >I can lay hands on a 64 bit machine.
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.