Computer Chess Club Archives




Subject: Re: no more comments???

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.
>>>>>>>>I did not ask about single example from endgame but about
>>>>>>>>the middle game or about rating improvement.
>>>>>>>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.
>>>>>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.


This page took 0.02 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.