Author: Robert Hyatt
Date: 19:03:05 03/30/03
Go up one level in this thread
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.