Author: Uri Blass
Date: 09:08:43 07/23/02
Go up one level in this thread
On July 23, 2002 at 11:44:29, Robert Hyatt wrote: >On July 23, 2002 at 11:00:26, Uri Blass wrote: > >>On July 22, 2002 at 23:12:15, Robert Hyatt wrote: >> >>>On July 21, 2002 at 14:56:12, Robert Hyatt wrote: >>> >>>>On July 21, 2002 at 14:54:18, Robert Hyatt wrote: >>>> >>>>>On July 21, 2002 at 01:29:38, Uri Blass wrote: >>>>> >>>>>>On July 20, 2002 at 22:20:29, Robert Hyatt wrote: >>>>>> >>>>>>>On July 20, 2002 at 05:55:43, Uri Blass wrote: >>>>>>> >>>>>>>>On July 20, 2002 at 05:47:38, Gian-Carlo Pascutto wrote: >>>>>>>> >>>>>>>>>On July 20, 2002 at 02:52:11, Uri Blass wrote: >>>>>>>>> >>>>>>>>>>My question was not about comparing using hash tables >>>>>>>>>>and not using hash tables but about comparing using hash tables >>>>>>>>>>in the normal way and using hash tables >>>>>>>>>>for all purposes except pruning. >>>>>>>>> >>>>>>>>>In the example given, the move ordering from hashtable is almost >>>>>>>>>irrelevant, so all the gains are due to pruning. >>>>>>>>> >>>>>>>>>-- >>>>>>>>>GCP >>>>>>>> >>>>>>>>I did not ask about single example from endgame but about >>>>>>>>the middle game or about rating improvement. >>>>>>>> >>>>>>>>Uri >>>>>>> >>>>>>> >>>>>>>I gave you an answer of sorts. Best case is fine 70. 3x as many plies. >>>>>>>Middlegame seems to be a factor of 2x in terms of time to reaching a specific >>>>>>>depth. So a fraction of a ply. So from early middlegame to endgame sees this >>>>>>>go from a fraction of a ply to (say) 30 additional plies... >>>>>>> >>>>>>>The 30 is important. It doesn't just happen in fine 70. It happens in lots >>>>>>>of important king and pawn endings. >>>>>> >>>>>>I know that in simple endgames you can get big improvement thanks to using hash >>>>>>tables for pruning. >>>>>> >>>>>>I also know that you can get a factor of 2 in the middle game from hash tables >>>>>>when the comparison is between using hash tables and not using them. >>>>>> >>>>>>It did not answer my questions. >>>>>> >>>>>>Only Christophe answered them when he explained that I may get 10% speed >>>>>>improvement in the middle game from pruning. >>>>>> >>>>>>Uri >>>>> >>>>>OK... I will take my usual approach and simply give you _real_ data. >>>>> >>>>>Three positions. The first tactical, the second just a middlegame position >>>>>with no real tactics, the last an endgame (fine70). All three searched with >>>>>normal hashing, and then using hashing as normal, but not allowing the hash >>>>>stuff to produce a fail high, fail low, or exact score. It can still tell me >>>>>to avoid a null-move search. The difference in times, then, is _totally_ >>>>>dependent on using the hash scores only, as everything else is identical. >>>>> >>>>> >>>>> hashon hashoff >>>>>Tactical 48 secs 78 secs >>>>>normal 118 secs 183 secs >>>>>fine 70 0 secs 58 secs >>>>> >>>>>In fine 70, both searched to 18 plies. hash on got right move (kb1 >>>>>winning a pawn). hash off did not get right move. >>>>> >>>>>You can draw your own conclusions. 10% is obviously _way_ too low. I >>>>>said roughly a factor of two, for middlegames, which is pretty close in >>>>>the first two. In the last position we _know_ what hashing does. >>>>> >>>> >>>> >>>>I should add, if you _really_ don't think that I answered your question, then >>>>maybe the question you actually _asked_ and the question you _meant_ to ask >>>>are not the same thing. I believe my previous post shows that I _did_ >>>>directly answer the question you asked. _exactly_... >>> >>> >>>I find it interesting that I answer the question, get accused of not answering >>>the question, then I post _real_ data showing that I answered the question, and >>>the discussion stops cold... >>> >>>why would that be??? >> >>I thought that your data about being twice faster was about using big hash >>tables against small hash tables and not about using hash tables for pruning >>relative to using hash tables not for pruning. > > >Think about it for a minute. If you use a tiny hash on a big search, what >are you doing? Answer: Using _no_ hash. Using the "hash_move" is not a >big winner to me in terms of tree size. What it lets me do is search faster >because I can try this move first without generating anything, and if I get >a cutoff, I get it with less work and go faster. If I disable the hash move, >then killers and captures simply work better, and the overall difference is >not very large. Except for the speed loss. > >If you use history moves for ordering, hashing is not going to be a huge >win if all you get is move ordering from it. If you do pruning, then the >question changes... I use hash moves only for ordering and it was clearly faster for me(about 1.5 times faster). I use also history tables and 2 killer moves. I still do not use hash tables to save generating moves and it is another gain that I can get from hash tables. Uri
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.