Author: Robert Hyatt
Date: 13:05:25 11/11/02
Go up one level in this thread
On November 11, 2002 at 10:39:23, Robert Hyatt wrote: >On November 11, 2002 at 05:00:25, Gian-Carlo Pascutto wrote: > >>On November 10, 2002 at 21:23:38, Robert Hyatt wrote: >> >>>As far as null-move, remember it only made a 3.0 vs 3.1 difference when we >>>ran those tests for Vincent a month or two back... >> >>Yes, but that is with a dynamic splitter that can handle multiple >>splitpoints. PVS cannot resplit. If it _already_ makes 0.1 difference >>with a dynamic splitter... :) >> >>The right thing to do would be to test this of course. >> >>-- >>GCP > > >I think my current code can be made to do this easily. However, the EPVS >stuff I did was "current" thru 1988 and we were using null-move R=1 back >then. EPVS was phased out and replaced by DTS in the 1988 ACM computer >chess event... > >However, back to the main point. 3.0 vs 3.1 with my current search says >(as I said many times) null-move does not have any significant influence on >parallel search performance. I don't see anything that says that a dynamic >algorithm will do better relative to PVS when you throw in null-move. I don't >see why adding null-move would affect PVS any more than DTS or my current >parallel search. Here is the PVS data I promised. From 1988 which means null-move, R=1, Cray Blitz. 2cpus was 1.83 times faster. 4cpus was 3.04 times faster. 8cpus was 4.08 times faster. 16 cpus was 4.59 times faster. These were using the 23 kopec positions (position 1, mate in 3, was deleted). Searched to a depth of 5 plies (the hardware was using a NS 32032 microprocessor, rated at .7 MIPS, searching maybe 50 nodes per second. 2 and 4 didn't look too bad, but 8 and 16 were horrible. EPVS took this to 2cpus was 1.88 times faster. 4cpus was 3.43 times faster. 8cpus was 5.35 times faster. 16cpus was 5.97 times faster. DTS (earliest version as of 1988, it was improved after that point quite a bit in terms of better ways to pick a split point): 2cpus 2.02 times faster (caused by two positions posting >2.5 speedups) 4cpus 3.73 times faster 8cpus 6.64 times faster 16cpus 9.61 times faster. Note the test setup... the machine was a 30 processor SMP (shared memory) machine (Sequent Balance 21000). Kopec test set searched to a fixed depth of 5 plies. Normal search extensions (check, recapture, passed pawn push, no SE back then). Null-move R=1 I think the shallow searches might have helped to bias the results since with so few plies, there were not many search extensions to trigger. I didn't remember PVS doing that well, as it is pretty close to my current algorithm for 2 and 4 processors. however, the kopec set doesn't have any simple endgames where PVS really has troubles, so that might have made a difference too. I probably ought to try to reproduce these tests using Crafty today, except 5 ply searches are so quick the timer resolution will have a major influence.
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.