Author: Vincent Diepeveen
Date: 06:57:34 03/31/03
Go up one level in this thread
On March 30, 2003 at 22:03:05, Robert Hyatt wrote: Hello, Apart from node count and search depths it is appreciated to post entire log.* files. Without trying Crafty yet at anything (precondition) i'll pick a few middlegame positions (in endgames things are clear enough anyway in favour of hashtable): 2rq1rk1/pb3ppp/1p2pn2/4N3/1b1PPB2/4R1P1/P4PBP/R2Q2K1 w - - 0 2 d5 pos.27 bs2830 d4d5 2r1r3/p3bk1p/1pnqpppB/3n4/3P2Q1/PB3N2/1P3PPP/3RR1K1 w - - 0 2 Rxe6 pos.5 bs2830 e1e6 rqr3k1/pp1bppbp/2np1np1/8/2BNP1P1/2N1BP2/PPPQ4/2KR3R w - - pos.0 Uri Blass corr a1a1 r1bqr1k1/pp1p1ppp/5n2/1N2n3/2P1PB2/6P1/PP1Q1K1P/4RB1R b - - 0 1 (d7d6) Uri Blass d7d6 The last position is to verify things. It should matter there. 4 positions will do here as the result is deterministic. With just 4 positions it is possible to calculate next: a graph hashtable speedups versus searchtime. For the 4th position assumption is it will give big speedup as there is more transposition possibilities and more king side checks there than in the other positions. On the other hand there is other problems there as well. As verification it is interesting to run the same 4 positions with 2 or 4 search threads to compare. My own findings is that a big hashtable size is very important for parallel search whereas at 3 minutes a move or so it doesn't matter much for a single cpu search (diep using 8 probes). >On March 30, 2003 at 15:09:19, Vincent Diepeveen wrote: > >>Bob of course didn't proof anything as usual and all significant counts are not >>shown. > >_nobody_ "proofs" anything by running test positions and giving the >results. That is a "demonstration" and _not_ a "proof". However, the >"significant counts" _are_ given. Total time to run the test, total >nodes searched, and the hash size. What else do you want? > > >> To start with also the solutions of positions at BT2630 are found within >>a second or so, so are no good positions to use for such hashtable tests. >> > > > >The solutions don't matter. What matters is the search space, which is large >whether it finds the correct move or not. And hashing helps whether the right >move is found or not. > > >>I need to note however that where when DIEP runs single cpu my results are very >>similar to what you presented here, when you are parallel, things change a lot. >> >>For programs that search in parallel it is very important to have a big >>hashtable. I see clear differences there in speedup when using big hashtable >>versus small hashtable. >> >>That difference is likely to explain the assumption from Bob versus your >>'proof'. >> >>Trivially the testpositions you used are better than the first 6 >>positions shown below: >> >>C:\engine\fen>type bt2630.fen >>rq2r1k1/5pp1/p7/4bNP1/1p2P2P/5Q2/PP4K1/5R1R/w >>f5g7 >>6k1/2b2p1p/ppP3p1/4p3/PP1B4/5PP1/7P/7K/w >>d4b6 >>5r1k/p1q2pp1/1pb4p/n3R1NQ/7P/3B1P2/2P3P1/7K/w >>e5e6 >>5r1k/1P4pp/3P1p2/4p3/1P5P/3q2P1/Q2b2K1/B3R3/w >>a2f7 >>3B4/8/2B5/1K6/8/8/3p4/3k4/w >>b5a6 >>1k1r4/1pp4p/2n5/P6R/2R1p1r1/2P2p2/1PP2B1P/4K3/b >>e4e3 >> >>Note that i am always amazed at how Bob picks his testpositions. > >How could you be "amazed" when you have no idea how I do it? I just >picked those as I had used them earlier and had the files set up to >run them. > >Feel free to suggest any 6 positions and I'll run 'em to show that _they_ >behave exactly the same for Crafty... > >You like to pick on test positions. You always claim yours are better. >When I run them (the deep blue positions come to mind) and get results >similar to results I get on my own positions, you run and hide and ignore >the results. > >So pick 6, post the FEN, and I'll run em again, same way. One thread, >with hash sizes from 48K to 384M, and post the same numbers again. Total >time used, total nodes searched, hash size used... > > > > > >> >>Best regards, >>Vincent >> >>On March 30, 2003 at 14:09:33, Tom Kerrigan wrote: >>>On March 30, 2003 at 10:50:44, Robert Hyatt wrote: >>> >>>>Now I hope you will choose to dump that "this disproves the hyatt claim" >>>>stuff, you clearly didn't disprove _anything_... >>> >>>I was of course referring to: >>> >>>"The simple rule is that the hash table needs to be at _least_ large enough to >>>hold the entire tree." >>> >>>Don't you think the word "need" is a little strong in this situation? I mean, >>>chess programs work fine without huge hash tables, so maybe they don't "need" >>>them. >>> >>>I notice that you didn't present any data on how much of the search tree was >>>being stored in the hash tables, and without that data you obviously can't point >>>to a significant performance increase when the entire table is stored, so I >>>don't see that you even touched on the issue, much less proved it or disproved >>>it. >>> >>>-Tom
This page took 0.01 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.