Author: Robert Hyatt
Date: 10:00:31 09/26/01
Go up one level in this thread
On September 26, 2001 at 11:39:05, Vincent Diepeveen wrote: >On September 26, 2001 at 11:19:04, Robert Hyatt wrote: > >>On September 26, 2001 at 10:48:14, Vincent Diepeveen wrote: >> >>>On September 25, 2001 at 23:44:09, Robert Hyatt wrote: >>> >>>you didn't turn off futility bob and i cannot see outputs >>>in number of nodes and such to see whether sequential overhead >>>mattered! >> >> >>I don't do futility pruning. I can't turn it off... >> >> >> >>> >>>Kopec positions are the worst testpositions ever to use anyway >>>for obvious reasons that the score only goes up and up and up. >> >> >>Not true. Crafty changes its mind several times per test position... >> >>The data shows that the speedup is pretty constant regardless of null-move >>or not. It would _also_ be constant with or without futility. Older versions >>had futility pruning and/or razoring. And it had no effect on the parallel >>search. >> >>If you want to make a wager, I will find the CB test positions and run >>them in the same way. You will see _no_ change in my speedup results, >>however... > >please run the positions and write down the speedups for 8,9,10,11,12 ply >of course for both 1 and 2 processors. 4 processors frommy viewpoint is >less interesting. > >game positions are *better* than positions where a few strategical >principles dominate and where some of the positions are too easy >to be true. you only get a score higher and higher! > >What you did here is compare apples with peanuts. depth 9 compared to >depth 10. That's stupid. It is only stupid to someone that doesn't understand the tree. You are _not_ going to search a position to 12 plies with no null-move, if it takes minutes to search it with R=2~3. I don't have all the time in the world to run these tests. Particularly when I _know_ the outcome before I run them. If you want to run tests, feel free to do so. But my time is limited and I don't want to waste it further. I compared the Cray Blitz numbers from the game, to the Kopec positions. There wasn't much difference. I wanted to use "game" positions because I was always asked "how does this speedup game searches, not test position searches?" I didn't know. Now I do. Roughly the same. > >What we need is the crafty OUTPUT simply from each run at this game! > >Easy to automate too. > I gave you the search time for each position, for each different test condition. What else is in the output that you need. _time_ is _the_ consideration in parallel search. Doesn't matter how many nodes you search. how many splits you do. How many stops you do. Just the total time is important, since that is how the game is limited. I gave you the data that shows your conclusions are badly flawed. I knew they were flawed before I ran the tests. I _still_ know they are flawed after the tests were analyzed. Nothing has changed. parallel speedup is independent of null-move, period. In fact, in general, null-move should do more harm than good, based on my Ph.D. dissertation analysis. Not a lot of room left to debate this issue. I'm not going to continue to rip out various pieces of Crafty's search, in an attempt to turn it into something that looks like yours. Crafty's search works just fine as it is, the parallel performance is just fine as it is. Null-move has no effect. A less restricted q-search will have no effect. Cray Blitz had a _much_ larger q-search than crafty, as it included checks, it tried all legal moves out of check, and it included some threats as well. It had _no_ problems at all with the parallel speedup and the numbers are fairly close to Crafty. CB was a bit better with 4 processors. Very close with 2.
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.