Author: Uri Blass
Date: 01:05:14 10/29/02
Go up one level in this thread
On October 28, 2002 at 15:13:23, Heiner Marxen wrote: >On October 28, 2002 at 14:06:54, Uri Blass wrote: > >>On October 28, 2002 at 13:17:56, Uri Blass wrote: >> >><snipped> >>>My question is if array is the fastest way to do other things like finding if a >>>rook move is pseudo legal. >>> >>>rook move is pseudo legal if the file is the same file or the rank is the same >>>rank(I can ignore the case when both are the same because this case never happen >>>and I never expect hash move or killer move when both are the same even in case >>>of hash collision) >> >>After thinking more about the problem it seems that my 2 dimentional array is >>not the same as checking if the move is pseudo legal because when I get the >>direction between the squares I get more information than knowing if the move is >>pseudo legal(the exact direction between the squares(left,right,up,down) >>and this information is used later. >> >>The main question if there is a fast way to calculate the function >>direction(x,y) when >>1)direction(x,y)=0 for up direction >>2)direction(x,y)=1 for down direction >>3)direction(x,y)=2 for left direction >>4)direction(x,y)=3 for right direction >> >>only a function that is faster than 64*64 array is productive. >> >>I am interested in the same question for bishop when direction(x,y) can get >>4,5,6,7. >> >>Uri > >Hello Uri, > >As you may have seen in the Chest sources, such a direction computation >can be done with a considerably smaller table, if you start off with >0x88 coordinate values. The table is indexed with the difference of the >two 0x88 coordinates, and has size apx 16*16 = 256 entries. > >I think, that the biggest problem with such tables is not so much their >own size, but the cache footprint they leave. That can severely slow down >the rest of the program. > >Whether some computational effort (function/macro) is faster than a table >lookup, heavily depends on the hardware, e.g. how large is the penalty for >conditional branches (when decisions are involved), and how smart is >the compiler to make use of special HW features to avoid conditional code >for simple conditional constructs (that is possible sometimes). > >I will ponder a bit about your exact direction function. >That could help Chest also, if really good, so I'm motivated :-) Another point is that for me a significant improvement can be if I have a good function to generate check moves. Today I use a slow function in order to make checks in the qsearch. I simply generate all the moves and later check for everyone of them if it is a check or not a check. It is faster to have a special function that generate the moves and calculate moves that are checks. The point is that a lot of moves are from the same from square so I do not need to check if the from square is in the same direction with the king if I do it in that way. It may be even better not to generate all the moves in the qsearch but if I do not count them then it is a change in the algorithm because the number of moves is used for evaluating mobility and I prefer first only to improve the speed of the program because it is more easy to check that there are no bugs(if the number of nodes is the same in a lot of positions there is probably no new bug). I know that checks in the qsearch did movei about 1.5 times slower in nodes per second because of my slow function to find if a move is a check but inspite of it my tests suggest that checks in the first plies of the qsearch are productive for movei. Uri
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.