Hash table

[stegemma]

If "exact" is bit 1 of "type" then you can avoid some conditional jump this way:

Code: Select all

   a1 += ~(h1->type - exact) & 1; 
   a2 += ~(h2->type - exact) & 1; 
   a3 += ~(h3->type - exact) & 1; 
   a4 += ~(h4->type - exact) & 1;

This works if the only type that is odd is "exact" and the others are even.

[hgm]

Of the examples shown in this thread, I tried hgm approach but was maybe 2 elo worst.

But how did you test that? From the graph you can see the equi-distributed draft did 25% better than equidistributed only at an overload of a factor 100. How much was the overload factor in your Elo measurement?

[stegemma]

Sorry, if exact is bit 0, it must be:

Code: Select all

a1 += (h1->type & 1);
...

[cdani]

Of the examples shown in this thread, I tried hgm approach but was maybe 2 elo worst.

But how did you test that? From the graph you can see the equi-distributed draft did 25% better than equidistributed only at an overload of a factor 100. How much was the overload factor in your Elo measurement?

Copying exactly your code. The other things I have done is to initialize to 0 the little hashCount array and to treat the quiescence/static eval entries. Maybe I did not understood something? Thanks

[cdani]

Sorry, if exact is bit 0, it must be:

Code: Select all

a1 += (h1->type & 1);
...

Yes thanks. I have yet to optimize the whole function.

[hgm]

Maybe I did not understood something? Thanks

Well, you did not understand my question.

I asked how large your hash table was (number of entries), and how large your typical search tree (time per move and nps).

[cdani]

Maybe I did not understood something? Thanks

Well, you did not understand my question.

I asked how large your hash table was (number of entries), and how large your typical search tree (time per move and nps).

Ah!

128 MB / 16 bytes = 8,388,608 entries
The games where at 50 seconds + 0.05
The typical nps are 850,000 at opening phase, and 1,150,000 at endgame.
The typical time usage is maximum of 2 seconds in a few moves of opening phase, descending rapidly to less than one second, and 0.20 seconds in deep endgame.

[hgm]

Well, if I do the math it seems that your typical search tree measures at most about 1.7M nodes, and later in the game only 0.23M nodes. (I don't know if you count hash cutoffs in this). The hash table is 4 to 40 times larger.

So basically you are trying to measure the differences between replacement schemes under conditions where virtually no replacement takes place...

[cdani]

Well, if I do the math it seems that your typical search tree measures at most about 1.7M nodes, and later in the game only 0.23M nodes. (I don't know if you count hash cutoffs in this). The hash table is 4 to 40 times larger.

So basically you are trying to measure the differences between replacement schemes under conditions where virtually no replacement takes place...

Mmmm... The worst attemps where clearly outside the error margins, so there was some big influence of the changes. Anyway I will try again the two or three best ideas with maybe 16 or 32 MB. Thanks!

[hgm]

Well, 1MB would be more suitable. The calculation above was for the total number of nodes. The number of different nodes in the tree (and thus the required number of hash entries) might be far smaller. Perhaps even as much as a factor 10. For one, each new iteration usually revisits the nodes of the previous iteration.