Author: Dan Newman
Date: 14:26:48 11/20/99
Go up one level in this thread
On November 20, 1999 at 08:59:11, Bas Hamstra wrote: >Hi Dan, > >Let me give you an idea of my current speed: it is comparable with yours, the >same order of magnitude, I think (also Celeron 450). Indeed make/unmake slow >down considerably, other things speed up, like you mentioned. I don't think it >is much faster or slower on the whole than the more conventional approaches. >Another interesting figure: with only material eval my profiler says my make is >7% as wel as the unmake. NextCapture() is 10%. Blocks() is 3%. > Wow. 7% on make is quite good I think. This is the same percentage I got for my 0x88 program in fact... Of course that's all relative to what other things take. In the 0x88 program the biggest cost was the SEE which took a full 25%. >The worst case is when a queen captures a queen, of course. But that doesn't >happen too often. When you just move a pawn it costs only a few ticks and you >have your (peudo) captures at hand. I don't think I have squeezed all speed out >of it, yet. For instance, in case of Q1xQ2 I remove attacks for the first queen, >than for the second, and insert new attacks for the first queen. Clearly that is >not optimal: better (I hope) would be to make a combined NOT mask for Q1 and Q2 >and just NOT all 64 squares in one run. > The only improvement I've thought of is to avoid toggling the bits along the diagonal or orthogonal along which a slider moves. This would (I think) cut the cost quite a bit for bishops and rooks and a smaller amount for queens. But would make the code a bit more complex. It would also increase the function call overhead and perhaps expand code that does the bit twiddling. >Another thing to consider that I have never tried is to make a copy of the >attackboard so saving the undoing of attacks. No idea if that's faster. > That sounds more expensive, but it's worth a try. >The fastest purely material (fully SEE sorted) program I wrote yet was a >bitboard approach. But then when I added some eval and some InCheck checking and >attack detection the difference became quite small. > Same here. I had thought (after a few experiments with bitboards) that 0x88 would be faster (on Intel machines), but now the fastest thing I've written is my current non-rotated bitboard program... >I am looking for ways to exploit my datastructures more. One example is: if a >pawn is at seventh I can easily determine wat the oppo has to sacrifice to >prevent promotion, by a SEE. Works quite well. Any ideas of where to use more >SEE's in eval succesfully? I am currently fiddling with counting pseudoattacks, >and assign a bonus for that (ignoring blocks) but without much success so far. > I haven't done much work on eval. Mostly I've been writing up to the point of getting a working program and then becoming dissatisfied with its performance or other characteristics (ease of programming, bugginess, lack of support by the basic data structures for some feature or important element, etc.). So I try something new. One thing I'm doing now is giving a slight bonus for sliders bearing on the king with the hope that the search will occasionally see something that leads it to a (successful) king attack. I have no idea whether it helps or not. With the pseudo-attacks one could also easily (cheaply) factor in attacks on squares surrounding the king too. As for the SEE, I only use it to order moves and trim losing captures in the quiescence search. I have though of trying to make it more sophisticated so that it can be used to replace the qsearch, but that may not be too practical... -Dan. >Regards, >Bas Hamstra.
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.