Author: Jeremiah Penery
Date: 07:50:48 09/04/02
Go up one level in this thread
On September 04, 2002 at 10:10:34, Vincent Diepeveen wrote: >On September 03, 2002 at 17:03:16, Jeremiah Penery wrote: > >>Perhaps you missed some of the threads from a while back (a year or so). >>Vincent has claimed to get >2.0 speedup on 2 processors before. I'm not sure >>why suddenly he changes this to 1.6 or whatever now. Seems to me he makes up >>whatever numbers he wants to 'prove' his points, because obviously whatever he >>says becomes a proof. > >There are 2 'deep' diep versions > a) diep version 1999-2002 (juli) > b) diep optimized for NUMA > >In both categories there is a substantial >difference in speedup between several versions: > a1) with dangerous extensions > a2) without dangerous extensions > a3) without dangerous extensions and with forward pruning > >a3 always has a > 2.0 speedup for simplistic reasons that it is >doing a dubious search. It is this version which had also a 4.0 speedup >in 1999 and which searched 20 ply in endgame in 1999 at 4 processors. So you're saying your serial search for that version sucks? >After that i have again experimented with forward pruning bigtime over >the years, but the version a2 is very close to a 2.0 speedup. If you >look to node counts of crafty you will see it also needs less nodes >than a single cpu search. I've never seen such a result. Every time, more processors requires some more nodes to complete the same search. >Bob denies it, but never shows node counts. What Bob needs to do is both >proof 1.7 speedup and at the same time show the node counts for every ply >at every depth while claiming that 1.7 speedup. Why do the node counts for each ply matter? Is not the final node count enough? Just search some positions to 15 ply or so with 1 and 2 processors, and compare total node counts. >Bob did do this for Cray Blitz obviously. However Cray Blitz used hardly >nullmove, so the chance that a branch gives a major cutoff in little nodes >is a lot less likely, whereas bob himself sees for crafty today already >a 2 ply increase using nullmove (i feel it is on average a LOT more >than 2 ply though for DIEP, because if i search with all extensions >turned on fullwidth i hardly get above 9 ply and only after billions of >nodes i get to 10 ply; only without dangerous extensions fullwidth a >ply or 10 is possible). What, again, does this have to do with parallel speedup? Can you stick to the subject? >I will not comment too long on the 2 ply estimate for crafty, but let's >do a simple run here at bob's favourite position (so the one where he >has a good speedup), without knowing now what the speedup is and let it >run for 30 minutes exactly: Why do you run only one position and claim it proves your point? You run with 2 processors to boot, which already introduces some error into the results. >2r2rk1/1bqnbpp1/1p1ppn1p/pP6/N1P1P3/P2B1N1P/1B2QPP1/R2R2K1 b b7e4 >moves: solution ; singlemove Bxe4!! >name : Bratko-Kopec.22 >Crafty v18.15 (1 cpus) > >White(1): ponder off >pondering disabled. >White(1): mt 2 >max threads set to 2 >White(1): setboard 2r2rk1/1bqnbpp1/1p1ppn1p/pP6/N1P1P3/P2B1N1P/1B2QPP1/R2R2K1 b <SNIP> > 27883394 13 23.56 -0.63 1. ... Bxe4 2. Bxe4 Qxc4 3. Qxc4 Rxc4 > 4. Nxb6 Rxe4 5. Nxd7 Nxd7 6. Bd4 Rb8 > 7. Rac1 Rxb5 8. Rc7 e5 9. Rxd7 exd4 > 10. Nxd4 > 35691370 13-> 29.91 -0.63 1. ... Bxe4 2. Bxe4 Qxc4 3. Qxc4 Rxc4 > 4. Nxb6 Rxe4 5. Nxd7 Nxd7 6. Bd4 Rb8 > 7. Rac1 Rxb5 8. Rc7 e5 9. Rxd7 exd4 > 10. Nxd4 > 60295418 14 48.61 -0.40 1. ... Bxe4 2. Bxe4 Qxc4 3. Qxc4 Rxc4 > 4. Nxb6 Rxe4 5. Bxf6 Nxf6 6. Rdc1 Rd8 > 7. Nc8 Nd5 8. b6 Re2 9. b7 > 136243127 14-> 1:48 -0.40 1. ... Bxe4 2. Bxe4 Qxc4 3. Qxc4 Rxc4 > 4. Nxb6 Rxe4 5. Bxf6 Nxf6 6. Rdc1 Rd8 > 7. Nc8 Nd5 8. b6 Re2 9. b7 > >Now the same version without nullmove: > >Crafty v18.15 (1 cpus) > >White(1): mt 2 >max threads set to 2 >White(1): ponder off >pondering disabled. >White(1): setboard 2r2rk1/1bqnbpp1/1p1ppn1p/pP6/N1P1P3/P2B1N1P/1B2QPP1/R2R2K1 b <SNIP> > 1203681300 12 14:15 -0.44 1. ... Bxe4 2. Bxe4 Qxc4 3. Qxc4 Rxc4 > 4. Nxb6 Nxb6 5. Bd3 Rcc8 6. Nd4 Rfe8 > 7. Nc6 a4 > 3625442403 12-> 44:17 -0.44 1. ... Bxe4 2. Bxe4 Qxc4 3. Qxc4 Rxc4 > 4. Nxb6 Nxb6 5. Bd3 Rcc8 6. Nd4 Rfe8 > 7. Nc6 a4 > 5277808477 13 63:23 -0.63 1. ... Bxe4 2. Bxe4 Qxc4 3. Qxc4 Rxc4 > 4. Nxb6 Rxe4 5. Nxd7 Nxd7 6. Bd4 Rb8 > 7. Rac1 Rxb5 8. Rc7 e5 9. Rxd7 exd4 > 10. Nxd4 > > >We see that a search of 15 seconds with nullmove takes 44 minutes >without. At tournament time controls the difference is already 3 ply. >After that difference is 5 ply, obviously caused by the better >branching factor. Obviously it depends on the position, but you could be right about this. I don't know, because I don't care to know the difference between using null-move and not using it in Crafty. Still, I don't think it has any bearing on parallel search efficiency/speedup.
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.