Author: Landon Rabern
Date: 21:38:34 01/29/01
Go up one level in this thread
On January 29, 2001 at 23:32:01, Dan Newman wrote: >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. Have you tried it with rotated bitboards recently to see if you get any improvement. Also, have you looked into using the MMX registers? I am getting about a 35% speedup using MMX. Regards, Landon
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.