Author: Uri Blass
Date: 11:07:15 07/23/02
Go up one level in this thread
On July 23, 2002 at 13:20:29, Robert Hyatt wrote: >On July 23, 2002 at 12:08:43, Uri Blass wrote: > >>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. > > > >Do you do hash move and killer moves _before_ generating legal moves? No. I do not do it. You are right that I can save there time. I use the information about the number of legal moves in my search in part of the cases for my extension rules but even in these cases I can save the number of legal moves in the hash tables and I may also consider to count the number of legal moves without generating them before killer moves. Uri
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.