Author: Dan Newman
Date: 20:32:01 01/29/01
Go up one level in this thread
On January 29, 2001 at 20:57:42, David Rasmussen wrote: >On January 29, 2001 at 20:21:32, Dan Newman wrote: > >> >>I'm currently getting about 1040 knps on a P3 running at 980 MHz with Shrike >>which uses non-rotated bitboards. I've been stuffing a lot of eval in too. >>A lot for me anyway. If I turn off lazy eval it drops to about 890 knps. >>(All this measured on WAC.) >> > >You really can't use nps for anything here because your definition of nps might >be different from mine etc. Also, you might have bugs in your nps counting. I >had one very common bug once, where I counted nodes at the beginning of my >Search() function, and then, if depth was <= 0, I called Quiescence(), where >nodes was counted too in the beginning, so the depth=0 nodes were counted twice. >And they are really a large part of the tree, so I got huge nps, until I >discovered the bug. > I've never had that bug :). I increment node counts at the top of search() and at the top of quiesce(), but I do like Bob does in Crafty and decide whether to call search() or quiesce() in the loop where the moves are tried, so the nodes can't be counted twice. I tried it the other way, I think about 5 yrs ago, but I always subtracted one before calling quiesce() to correct for this. I don't think my definition differs very radically from most people's definition of nps. There are of course minor differences related to whether you use the search to find illegal moves (amongst the pseudo-legal moves) or employ a special test function (as I do). I think the general idea is to count something as a node if you actually make the move and update the basic board and other data structures and recurse into the search routine. I guess if you count nodes in make() and call make() as part of your move vetting procedure, that would inflate things somewhat...but maybe it ought to... In general I agree nps usually means very little when comparing different programs; it's what you do with the nodes that counts. A better measure might be something like time-to-depth, but even that has flaws since a really complex eval or set of extensions might make up for a smaller nominal search depth. I guess I should also have included the node rate of my 0x88 program for comparison. A lot of the code is the same in the two programs, but the later (bitboard) program has had a lot of stuff added--mainly eval. On WAC at 1s/posn I get 1044 knps with the bitboard and 946 knps with the 0x88. And the 0x88 has much less in the way of eval. It is really hard to argue that the comparison has much validity though. They are different programs with different amounts of tweaking, and so forth. The SEE functions are implemented somewhat differently, for instance--due to the basic data structures being different. But my gut feeling is that the extra speed is mostly from using bitboards. >>I Used to use 0x88 (and have tried a lot of other things too) but am finding >>bitboards to be somewhat faster for some reason... >> >>-Dan. > >Maybe your 0x88 implementation was slow? >I don't know. I know that Crafty doesn't run 1000 knps at 980 MHz. The first time I tried bitboards I found they were only about half the speed on move generation as my then current program (which may or may not have been 0x88). I gave bitboards a pass. For some reason I tried them again and was very surprised at the result I got. I think the extra speed I found the second time around was due to several factors: 1) I used the MSVC compiler (I had been using Watcom). MSVC seemed to "amplify" the difference. 2) I switched to non-rotated bitboards which are much lighter on the cache than rotated (I suspect). I still use some board scanning for sliding moves which I suspect is faster on P3's. 3) I changed from table lookup to using the BSF/BSR opcodes to extract bit indices. I also suspect that bitboards allow you to eliminate more branches than 0x88 and do more straight-through code with lots of operations to fill the pipes on a P3. What I really like about bitboards is that they seem to make a number of things simpler or more straight forward, due principally to the elimination of the piece list which was always a hassle (for me at any rate). -Dan.
This page took 0.02 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.