Author: Gerd Isenberg
Date: 03:46:18 10/16/03
Go up one level in this thread
On October 16, 2003 at 05:53:17, Uri Blass wrote: >On October 16, 2003 at 05:07:43, Gerd Isenberg wrote: > >>On October 16, 2003 at 03:16:58, Axel Schumacher wrote: >> >>>Hi, >>>I stumbled across the new engine Gothic Vortex, which seems to be a 80 bit >>>engine! What is your opinion to this approach? >> >>Hi Axel, >> >>an interesting chess vaiant with 10*8 board and two new pieces, the "Chancellor" >>combines Knight and Rook, "Archbishop" Knight and Bishop. >>I only know about the Archbishop in "Janusschach", also with 10*8 board, but >>with two Archbishops per side between Rook and Knight in the initial position. >> >>Some statements in the paper are questionable: >> >><snip> >>>... However, not all computer operating systems perform native >>>64-bit math manipulations. So, 64-bit program code is "emulated" by using pairs >>>of 32-bit constructions. >>> >>>Such emulation slows down the overall performance by at least a factor of two. >>>But what other choices does one have? >> >>Considering internal datapathes are already 64-bit or more in current 32-bit >>cpu's and 32-bit instructions are shorter and may processed simultaniously, that >>statement seems to be too optimistic. >> >>The problem with current 32-bit architectures like x86-32 is the lack of 32-bit >>registers. >> >>> >>>It is possible to use an Array Move Generator. Most programmers who attempt to >>>write something as complex as a chess program first build an Array Move >>>Generator. On the plus side, an Array Move Generator is easier to program and >>>debug. It also "makes sense" to think in terms of an Array Move Generator, since >>>the computer instructions used to encode the program closely resemble the >>>process a human player might use to do the same thing. On the minus side, an >>>Array Move Generator is many times slower than a Bitboard Move Generator. A >>>recent experiment showed that the Bitboard Move Generator in the Gothic Vortex >>>program is about 30 times as fast as the Array Move Generator found in the >>>Zillions-Of-Games engine. >> >>Ok, i guess the "Array" Move Generator is simply a very "bad" implementation. >>And as we all know Move Generation is at most a negligible part of a chess >>engine. > >I think it is dependent on the engine(an engine may generate moves as part of >its evaluation function and give a score for every move) Yes, if you have appropriated attack data structures with some precaculated stuff, move generation is most likely a waste-product. Therefore isolated move generation comparisons doesn't make so much sense, IMHO. > >Note that I do not understand how can you be 30 times slower with an array. > If the challange is to slow things down, no problem with some wait loops inside ;-) They use rotated bitboards with precalculated lookup tables. Vertical and diagonal occupied states to index with are still eight bits, with only the six relevant inner bits. The horicontal states are ten bits, where the eight inner bits are relevent for control states on a 10-bit rank. I don't know the "zillions of games" approach. Even if you scan directions and check for outside board everywhere, factor 30 looks very strange. Gerd >I have arrays for king moves and for knight moves > >something like: >kingmove[64][8] >knightmove[64][8] >numkingmoves[64] >numknightmoves[64] > >It may be not the best way to generate moves and it is possible that something >like 16 bit int array >directionkingknight[64] and a loop on the directions may be faster but >I do not think that it is so slow that it is possible to find the relevant >squares and to check the color of the target square 30 times faster. > >Uri
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.