Author: Vincent Diepeveen
Date: 10:23:24 01/09/04
Go up one level in this thread
On January 08, 2004 at 05:17:48, Gerd Isenberg wrote: >On January 07, 2004 at 14:25:48, Andreas Herrmann wrote: > >>Hi Ed, >> >>i'm just reading in your Rebel internals about your attack tables, they are >>totally diffrent than mine, but i like your structure. >>But how do you handle more than 1 attacker from the same kind? It seems that >>this is not possible in your structure, or have i overread something? >> >>What about the following, if using a 16 bit integer: >>Bit 1 to 3: total number of attackers >>Bit 4 to 5: number of attacking pawns >>Bit 6 to 7: number of attacking bishops and knights >>Bit 8 to 9: number of attacking rooks >>Bit 10 to 11: number of attacking queens >>Bit 12 to 16: free for other stuff >> >>Ok this needs more time to fill, and the calculating of hanging pieces needs a >>much bigger array, which gives me a result back, but i could handle all kinds of >>attackings. >> >>thanks in advance for your answer >>Andreas > >Hi Andreas, > >it's a tradeoff between space and accuracy. Ed's byte values allow a fast table >lookup whether a piece is enprise or hanging or whether a square is safe to >enter with some piece for one side: > >get_next_piece_on_the_board // scan the board >// get status via the bits >status = TABLE [piece_type] [WB[square]] [BB[square]]; >if (status == 0) continue; // piece safe -> next square >else: piece hangs, status contains its value // Q=9 R=5 B=3 N=3 P=1 > >char TABLE [12] [256] [256]; // about 860 Kb unsigned char of course if you mix types anyway, otherwise compiler has that 'treat all chars as unsigned' mark set anyway. Also i'm against type mixing anyway. You cannot convince me that a huge program you make 0 mistakes with type mixing. I'm simply using 'int' everywhere in search of diep. Yes i know 'unsigned int' is faster, and a lot. But the principle is wrong and asking for bugs. Yet even 860KB is just too much to be true for todays processors. You gotta be joking bigtime there. My MP2600 has just 256KB of L2 cache. A lookup to L2 cache costs 23 cycles. So you lose that penalty for sure. When just using logics knowing most branches are predicted or rewritten to P6 code automatically by compiler, and you have even other tricks. By the way, important question: (x != 0) , do ANSI-C '90 conventions garantuee me that this delivers a 1 always when it is true? My book just tells me it is only a 0 when it is not true and non-zero when it is true. I'm not limited to x86 nor x86-64 in this respect. Back to the normal way of optimizing code. So i lose a constant amount of time to quick code, now your 860KB table. About 400ns at a dual K7 you will suffer at regular intervals. Also you will trash the L1 cache, Trash the L2 cache. Note that i would be amazed if Ed has such huge arrays in Rebel. I predict a lot of branchless code where suffering 20 cycles penalty and sometimes 800 cycles penalty is really a lot more. At opteron you suffer 15 cycles penalty to get something out of L2 cache. but your code will very regurarly, even at P4's catch major penalties even at 800Mhz bus P4 3.4Ghz EE : 280 ns * 3.4Ghz P4 EE = 952 cycles. That's death penalty just for a single table. >If you use a more accurate 11-bit word, the table size becomes >2**6 = 64 times bigger: > >char TABLE [12] [2048] [2048]; // about 48 Mb > >I guess that huge lookup-table don't pays off. > >Cheers, >Gerd
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.