Author: Ren Wu
Date: 17:57:53 09/26/01
Go up one level in this thread
Here is Initiative's log, two pos ecm 1582 and ecm 1527, searched up to 8 plies.
383.008 16.0 383.008 16.0 1809781 _Attacking (rcgen.obj)
269.220 11.2 269.220 11.2 169580 _GenCapMove (rcgen.obj)
256.254 10.7 2220.588 92.6 967692 _NegaScout (rcsech.obj)
226.982 9.5 226.982 9.5 967693 _HashTableLookup (rchash.obj)
213.103 8.9 213.103 8.9 1719790 _Update (rceng.obj)
206.721 8.6 206.721 8.6 849079 _NextMove (rcsech.obj)
177.683 7.4 189.571 7.9 78714 _GenAllMove (rcgen.obj)
117.972 4.9 117.972 4.9 2 _HashTableClear (rchash.obj)
80.751 3.4 86.419 3.6 42184 _ScorePawn (rceva.obj)
74.670 3.1 435.134 18.1 78714 _SEMoveGen (rcsech.obj)
74.464 3.1 209.035 8.7 782713 _RCEngScore (rcsech.obj)
53.791 2.2 53.791 2.2 1719790 _Dndate (rceng.obj)
48.165 2.0 134.571 5.6 782715 _EvaPawnStruc (rceva.obj)
40.769 1.7 469.323 19.6 227145 _CapSech (rcsech.obj)
Compare this with yours, from first few lines, things looks ok. However, i saw
this from yours
[6] 66.5 0.43 21.46 1642284+928083 qsearch [6]
5.26 4.70 2570367/2570368 opn_eval [7]
2.48 3.01 1613239/2066384 gen [8]
1.03 3.94 1584298/2036996 order_moves [9]
is this quiese search routine? it tells me that it took about 2/3 of the time, i
think this is a problem, which position are you using here?
Mine only took 20% of the total time, and i don't use SEE, and so in theory I
will search more capture nodes than you. Maybe your pruning code at quiese
search borken, and so you end up search more nodes there, and because you use
SEE, those nodes are expensive to search.
try to get rid hash probe at capture, and use MVV/LVA to sort moves and see if
helps.
I am not sure if this help in anyway, good luck.
btw mine get about 500K nps on a PIII-733. So I think yours can be speed up
quite a bit.
Ren.
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.