It should be noticed, that this tournament now seems to be performed with double speed compared to the scheduled intended playing dates. I welcome this, because we all are interested in having its results more early. Thus I have to thank the organizer for this acceleration.
There is a small question left about SMIRF's games. I have tried to replay the Vortex meetings. Even when the timing is hardly to be reproduced, the occuring evaluations of SMIRF should be matching. Therefore I presume there is a small difference caused by selecting a cache size of 128MB for SMIRF instead of the intended 256MB. Even if this should be not that relevant, I suggest to chose the latter doubled value for the remaining games, it would be nice.
Thank to all involved people for making possible this GothicChess event.
Subscribe to:
Post Comments (Atom)
6 comments:
SMIRF always remembers its last cache setting and I have this set at 256 MB. It is being run on a machine with a 2.4 GHz processor when I have been doing the tournament. The last several rounds have been played by the Martillo programmer in Australia on 2 machines with 2 helpers. He has been giving me the results but he has been slow in getting the moves to me so that I can make them available for replay.
If you have a specific postion that you are talking about, let us know.
Well, then forget about that. It is hard to replay games identically upon different hardware. So excuse my misinterpretation.
From what I have seen, once SMIRF settles on a move, even if it were to search say 5 minutes, it usually will play the same move. The only time SMIRF changes its mind is from 0 seconds to about 1 minute. Of course there are exceptions to this, but what I have described fits the vast majority of cases that I have seen.
Something like this was just being discussed in an online board
Effect of Hash Tables on Producing Different Games
A quote from the article:
I think I've seen happening more frequently than some people would expect or it could be an influence of small timing differences as Robert Hyatt says, leading to different games from identical set-ups. I don't think it happens in Analysis mode though, only in games.
But shouldn't a program always make the same move every time it searches from the same position? I don't see why this would change just because of hash tables.
Hash tables add to the variability of program moves, because the move does not only depend on the position and search time, but also on what is left in the hash table from the previous move (which effectively alters the time needed to search the same tree).
Most programs do not play entirely reproducible anyway, if they keep an eye on the clock. The clock time is not really locked to the number of instructions executed by the program, because operating systems steal part of the CPU time for all kind of background processes, and some programs use information from disk (e.g. probing table bases), which introduces unpredictable mechanical factors related to rotation speed.
I experimented with micro-Max against Eden (two programs that play quite reproducible), and it turned out that once every 30-40 moves they play different from the same position.
Post a Comment