Author: Dieter Buerssner
Date: 09:04:23 01/23/01
Motivated by the engame postion Uri posted recently here, [D] 8/8/p1r5/6k1/KP6/8/8/5R2 b - - 0 1 and some changes I wanted to try with TB probing strategy, Dann Corbit was doing and experiment, on how Yace performs on this position (and also on the position after the loosing move Rb6). Yace analyzed the position for 2 hours with different settings for hash tables and EGTB cache. The target was to find Rc2 or Rc3, which probably both are drawing. The version of Yace used for the experiment does aggressive probing of the TBs during the whole search, but not in qsearch. I earlier indicated, that on my computer this can lead to much reduced performance in terms of nodes per second (sometimes only 20%). Dann gave Yace 256 MB of memory, which were distributed between hash and cache. A 2/254 8/248 32/224 128/128 224/32 248/8 254/2 B 129 - 29.2 30.2 19.7 27.9 46.3 C 42 - 8.5 9.6 6.3 9.8 15.9 D 183 29 41.2 52.1 36.7 49.8 52.7 E 78 10.4 13.1 16.7 13.7 19.5 18.6 F 19 17 17 18 17 18 18 G 23 24 24 26 27 27 28 H 63.4 69.7 92.6 116.5 135.2 137.5 140.1 I 490 402 348 240 224 213 203 J 67 34 20 19 10 12 16 A: hash/cache in Megabytes B: time to fail low on Rb6 in seconds C: million nodes for B D: time to find a better move (usually Rc3, sometimes Rc2) E: million nodes for D F: depth at which Rb6 was avoided G: search depth finished after 2 hours H: hash efficience in probes successful/positions stored I: performance in knodes/s after 2 hours J: time to find the force mate after RB6. In the first 2 columns the mate was found at depth 17, in the other columns at depth 16. Ususally a mate in 48 was found first and a mate in 44 at the next depth. Hardware: Athlon 950, 512 MB RAM, all 5-men tables, 100 GB disk. First the obvious. The more cache used, the faster were nodes/s (not too surprisngly) But one has also to take into account, that after each successful TB probe, the position is immediately stored in the hash, so that the hash also helps to avoid disk accesses. Then the solution times. They are not totally comparable, because the depth, at which the solution was found was different. At lower depth Yace shows almost the same scores after Rb6, Rc3 and Rc2. With different information resident in the hash tables, the move Rb6 can be avoided a different depths. Nevertheless, there is the trend of using less time for more hash. This trend is also confired by the time used to find the forced mate after Rb6. With the forced mate, it is more obvious, that with very little cache, the time rises again significantly. With my own test (with only 32 MB of memory) I have found, that the aggressive probing of TBs will lower many solution times, not only in this position, despite the fact, that the performance in nodes/s was often less than half of the performance without aggressive probing, and sometimes only 20% of the performance without using TBs at all. With Dann's much better hardware, such an extreme effect cannot be seen. If I also take the results of the position after Rb6 into account, and results of in between values for hash cache (not shown) 16 or 32 MB for TB cache and the remaining for hash seems to be a good choice. With very large EGTB cache the performance looks much better (in this case almost all of needed TBs may fit into the cache), but due to the smaller hash, more time is needed to reach the same search depth. Perhaps, to interpret the results it may be interesting to know, at which rate the hash is filled. I estimate something in the order of magnitude of 5 MB/s for the conditions above. Thanks to Dann for contributing his (computer)time, Dieter
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.