Author: Tord Romstad
Date: 08:42:43 12/22/05
Go up one level in this thread
On December 21, 2005 at 17:09:02, Andreas Guettinger wrote: >I agree in sense of portability asm code is bad, I don't like it too. In my very subjective opinion, the problem is not only portability, but also aesthetics. When I find myself having to use assembly language in order to achieve good performance, I usually decide that I should use a different data structure or a different programming language. >Crafty >falls back to plain C code for FirstOne(), LastOne() if no inline_asm or >inline_ppc is used. For the G4 I found the speedup to use cntlzw instead >neglectable (maybe 5%). Surprisingly this seems to be different for 64bit. >Crafty seems to rely heavily on these bitcounting function, but that may be >different for other engines and they may not profit a lot from the asm code. I'm afraid it would be the same thing for Glaurung. I use a lot of loops through the non-zero bits of a bitboard, and I use bit counting for mobility evaluation. >Additionally the C lookup table approach of crafty that replaces the asm >functions might be not the fastest for ppc. There was a thread some time ago >where different algorithms where compared (magic bitscan, table, gerd, eugene, >etc. ) I still have the source for them lying around somwhere. I use the following one in Glaurung: const uint32 BitTable[64] = { 0,1,2,7,3,21,16,35,4,49,22,52,17,66,36,80,5,33,50,70,23,86,53,96,18,55,67, 102,37,98,81,113,119,6,20,34,48,51,65,71,32,69,85,87,54,101,97,112,118,19, 39,64,68,84,100,103,117,38,83,99,116,82,115,114 }; inline uint32 first_1(bitboard_t b) { return BitTable[((b&-b)*0x218a392cd3d5dbfULL)>>58]; } The last time I checked, it was faster than the other non-assembly language alternatives on my G5. The code was posted by Gerd, I think. Tord
This page took 0 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.