Author: Uri Blass
Date: 14:15:06 08/10/04
Go up one level in this thread
On August 10, 2004 at 16:02:37, Robert Hyatt wrote: >On August 10, 2004 at 15:32:57, Uri Blass wrote: > >>On August 10, 2004 at 12:52:28, Robert Hyatt wrote: >> >>>On August 10, 2004 at 10:59:29, Tord Romstad wrote: >>> >>>>On August 10, 2004 at 10:35:29, Anthony Cozzie wrote: >>>> >>>>>Plus, if you have only PST eval you should be getting 3-4M nps, so SEE probably >>>>>slows you down a _lot_. >>>> >>>>Yet another proof of how bad my programming skills are. With PST eval and >>>>nothing >>>>else, I get about 800,000 nps (on a PIV 2.4 GHz). Adding SEE slowed me down to >>>>around 750,000 nps. >>>> >>>>Tord >>> >>> >>>SEE slowed me down by 10%. Move ordering improved to speed me up 10%. >> Washed >>>out to no advantage, _until_ I added the stuff about tossing out captures that >>>can't bring the score back to within the alpha/beta window. >> >>I doubt if you can give one number for speed improvement thanks to better order >>of moves. >> >>I think that the improvement can be bigger at longer time control. > >I don't believe the "percentage" will change, as I used long time controls for >all my testing... I don't pay much attention to blitz except to spot gross >problems... For every long time control there is longer time control and if you did the test some years ago the hardware got better. I do not see reason not to believe that the percentage will change because better order of moves should give bigger improvement in longer time control. > > > > > >> >> >> >> That made me about >>>2x faster overall, which is a _big_ gain. >> >> >>2xfaster overall only thanks to pruning? >> >>It seems to me too much advantage for SEE. > >I only report what I get. > >Hsu asked the question, I (and Stanback and others) ran the tests to see. > >> >>Note that even without SEE you can prune in the qsearch captures that cannot >>bring the score to alpha/beta window and if you are queen down relative to >>alpha then it is clear that capture of a rook will not bring the score back to >>alpha even without SEE so if the first version did not use that pruning you have >>not fair comparison. > > >That's a gross case. What about the case where the window is X, the current >material is X-2.00, and now you need to know whether the capture will bring you >back into the window. A good SEE score is _way_ better than MVV/LVA, as MVV/LVA >would say that QxR is ok, where SEE would say -4 since the rook is defended. > >The test was simply "normal q-search" with pure losing captures thrown out with >SEE vs normal q-search ordered by MVV/LVA." > >The current approach is a bit better than even that experiment of course. If I understand correctly You claim that only pruning captures in the qsearch based on SEE did you twice faster(better order of moves only compensate for being slower and not more than it. I find it hard to believe when I remember that I checked that even with tscp simple approach that does not have SEE only near 20% of the nodes are qsearch nodes so even if you save all the qsearch you still do not get being twice faster and pruning bad captures based on SEE does not save all the qsearch nodes. Uri
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.