Author: Tim Foden
Date: 14:37:50 12/05/03
Go up one level in this thread
On December 05, 2003 at 14:33:26, Dieter Buerssner wrote:
>On December 05, 2003 at 13:48:41, Tim Foden wrote:
>
>>For this position... [GLC]
>
>> 6 37.534 +4.489 21484k Rxh6 Rxb1+ 2. Kxb1 Qfxh6 3. Qxd8 Qexd8 4. Qxc8
>> Qxc8 5. Rxg8+ Kxg8 6. Qxh5 Rxa3 7. Qhxh4 Rxa2 8.
>> Qxh6 Rxa4
>
>Hi Tim, interesting statistics. Would you mind to explain some of it?
>
>> stats: fh=96.9%/1.14%/0.674% draws=10
>
>I think, I can guess the first number, but what do the remaining numbers (incl.
>draw) mean?
fh on first move/second move/third move.
draws gives then number of draw positions encountered during the search.
>> trans: probes=1282039 hits=229767 (17.92%) draft=163348 (12.74%)
>
>Do you probe in qsearch?
No.
>21 million nodes and only 1.3 million probes;
Yes, still lots of q-search nodes. probes is the number of positions in which
GLC looked for a match in the transposition hash table.
hits is the number of times the probe successfully found a hash key match.
>but then
>again, for a 6 ply search excluding qsearch, there should be less than 1.3
>million nodes?
>
>What does draft mean? (draft stored >= current remaining depth ?)
Yes. This gives the number of times we find a hash hit where we can use the
score info to cut if we want.
>I mainly recognized this, because in such positions, I get quite a bit a smaller
>hit ratio. By default Yace probes (and stores) in qsearch. I do limit qsearch,
>but a bit less than you. It needs longer to reach the depth.
>
> 77102928 3:13.9 4.97 5. 1.Rxg8+ Qfxg8 2.Rxh6 Rxb1+ 3.Kxb1 Qb7+ 4.Q3b4
> Qxb4+ 5.Q4xb4 Q5xh6 6.Qxd8 Qxe1 7.Qdxe1 Qxc1+
> 8.Kxc1 Qxd8 9.Bxd4 Bxd5 {501}
> 126341037 5:13.2 4.77 6t 1.Rxg8+ Qfxg8 2.Rxh6 Rxb1+ 3.Kxb1 Q7xh6 4.Qxe8
> Qgxe8 5.Qxh5 {1502}
>exit
> 146964349 6:05.0 4.77 6u. 1.Rxg8+ Qfxg8 2.Rxh6 Rxb1+ 3.Kxb1 Q7xh6 4.Qxe8
> Qgxe8 5.Qxh5 {1502}
>
>146964349 Nodes, 98.05% Leavenodes, 402548 Nodes/sec
>htable: 128250644 store, 324 rejected, 143235236 probe, 10.8% f/p, 12.0% f/s
>
>
>And with probe/store disabled in qsearch:
>
> 131818955 4:34.7 4.97 5. 1.Rxg8+ Qfxg8 2.Bxb8 Nb3+ 3.Qbxb3 Qhxc1+
> 4.Qaxc1 Qxc1+ 5.Qxc1 {HT} {1341}
>exit
> 163268370 5:37.1 4.97 5f. 1.Rxg8+ Qfxg8 2.Bxb8 Nb3+ 3.Qbxb3 Qhxc1+
> 4.Qaxc1 Qxc1+ 5.Qxc1 Qxa4H {HT} {340}
>163268370 Nodes, 99.50% Leavenodes, 484273 Nodes/sec
>[ ^^^^^^ ^^ Grrr ..]
:) In GLC this bit (2.1% / 97.9%) gives the % of normal nodes / % of q-nodes.
This position is simple a q-search killer!
>htable: 78739 store, 0 rejected, 82969 probe, 12.0% f/p, 12.6% f/s
>
>Note the few probes. I count Leafnodes only after the first level qsearch (a
>first level qsearch without any further recursion will not count any leafnodes)
>
>f/p means number found (independent of draft)/number probes
>f/s: s for number of stores
>
>> ehash: probes=0 hits=0 (-1.$%)
> ^^^^^ ?
I've experimented with an evaluation hash table, but it makes little difference
in GLC. Currently it is switched off, but I forgot to remove the stats. The
-1.$% is due to a division by zero in the percentage calculation.
>In "normal" positions, I thought my f/p ratios where about as numbers I had seen
>posted. But at least here, you do much better.
Ah, but in other positions Yace does much better...
e.g. here (game between GLC 3.0.3.4 and Delfi 4.1 - GLC lost)...
[d]1r2r1k1/2p1qppp/p1npbn2/4p3/1PP1P3/P5PP/1BQRNPB1/4K2R w K - 5 19
Yace 0.99.50:
htable: 25997367 store, 837 rejected, 30548733 probe, 18.3% f/p, 21.5% f/s
GLC 3.0.3.5:
trans: probes=4837070 hits=500120 (10.34%) draft=334125 (6.91%)
> I use a "cluster" of 3 entries
>per hash-index, which has some internal structure. At store time, I basically
>always replace the entry, which seems worth least. I can maximally store one
>score per entry (but want to experiment with two, soon - one upper and one lower
>bound).
>
>Do you do something significantly different? Might also be interesting, what the
>hit-ratio of other engines is in this pos.
I currently use the 2 table approach, one with replace limited by draft, and one
always replace (twice the size), so although each position can only map to at
most two entries, there are kind of 3 entries available.
A change I made for GLC 3.00 was if two entries had the same hash key, I chose
the one able to make a cut-off if there is one.
I've experimented with other ways, but so far this is the best I've found in
GLC. I still want to experiment with some more though (e.g. what about storing
best 2 moves??, or 3 hash entries in 32 bytes??).
I would certainly seem to make sense to have all the records for an index be
bunched close together (rather than in separate tables) so only one read is
needed... this is still on my todo list!
>Cheers,
>Dieter
>
>PS. Congrats to the nice showing of GLC in Graz
Thanks. GLC was lucky... but you need luck in these things. :) It was fun, and
it was nice to finally be able to meet people who I've "talked" to on the net.
Cheers, Tim.
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.