Author: Bob Durrett
Date: 06:39:21 09/01/03
Go up one level in this thread
On August 31, 2003 at 21:43:25, William Penn wrote: >On August 31, 2003 at 21:18:58, Ross Boyd wrote: > >>On August 31, 2003 at 19:44:28, William Penn wrote: >> >>>The more hash I allocate, the slower the kN/s speed. Thus 4MB (the minimum) is >>>the fastest in my tests, typically about 450kN/s. If I increase that to say >>>256MB hash, the speed slows down to about 400kN/s. The more I increase hash, the >>>slower the kN/s speed. >>> >>>The kN/s speed peaks, then eventually starts to decrease. How long this takes >>>depends on the amount of hash. However in my tests, the long term speed >>>advantage of bigger hash never catches up with the long term speed obtained with >>>smaller hash. Thus I don't see any advantage whatsoever to using a hash table! >>>The opposite seems to be true!? >>> >>>I'm using the Shredder7 GUI, Shredder 7.04 UCI engine, AMD XP Athlon 2400+/640MB >>>RAM (608MB available). The GUI says the maximum I can allocate to hash is about >>>455MB, so I'm not near the limit. Of course I'm using fairly common practical >>>positions for these tests in Infinite Analysis mode, and the above indicated >>>results are typical. >>> >>>I get very similar results running Shreddermarks with different size hash. The >>>more hash, the lower the Shreddermark and corresponding kN/s. >>> >>>Now, will someone please refute this, or explain what I'm missing or >>>overlooking? Thanks! >>>WP >> >>Increasing the hash size will tend to lower the NPS in most engines. >> >>Its kind of hard to explain why this is so... but I'll try. When an engine gets >>a hit in the hashtable it often cuts short the amount of exhaustive quiescence >>searching where NPS tends to go high. Nearer the root there is generally more >>overhead involved, with for example, more sophisticated move ordering etc... >>whereas the move ordering at the QS tends to be cruder and hence faster. >> >>Anyway, its not a bad thing.... >> >>What is more important is the total number of nodes visited to get to a certain >>depth. You will see that increasing hash size will tend to reduce the tree... >>and therefore (even though NPS drops slightly) the actual time taken to get to a >>given depth is reduced (usually). >> >>Time how long Shredder takes to get to a given depth, and also the total nodes >>visited, with various positions for two hash sizes. You'll see the true benefit >>of increasing the hash size. >> >>If you turn off the hash altogether you'll see the NPS increase a lot... but its >>not going to play stronger that's for sure... >> >>So, NPS is not a measure of strength. Really, its only useful for comparison >>purposes of the same engine with the same hash size on 2 different PCs. >> >>Hope this makes sense... >> >>Ross > >Gotcha! >Thanks. >I needed that clarified. >I have indeed noticed that I get about 1 ply deeper in a certain amount of time >(say 1 hour) when using maximum hash on this box. I'll run some more tests and >confirm it. > >Another important point to me is... > >Preferably the user should be able to access the best analysis "so far" in >Infinite Analysis mode (or other modes), but that option apparently isn't >available. Thus I must sit & wait & hope that it will deign to contact me with >its internal results before I go to bed. It's unpredictable. Sometimes it takes >a few minutes, sometimes several hours before the next analyis clip appears in >the engine window. Is there something I'm overlooking? Is there any way to >access the best analysis to date without stopping ongoing analysis in Infinite >mode, or some way to make it spit out those clips more frequently? I'd like to >see a clip about every 10-15 minutes, but at least one per hour at a minimum!? >Thanks, >WP I do not have a direct solution for you but you may wish to try some of the following ideas. They work fine with Fritz 8, Tiger 15, Deep Junior 8 [single processor], and Shredder 7. I use infinite analysis mode in three scenarios: (a) Unattended overnight analysis of a game. (b) Attended, with me watching at least occasionally. In this case, I am usually allowing the chess engine to run in infinite analysis mode in the background while I'm working on something else in a different program [such as Word, Excel, Internet Express, etc.] I occasionally return to the engine output to see how it's going. Having 2 GB RAM makes this practical. (c) Attended, with me actively steering the analysis making the engine look at MY ideas. In scenario (a), I don't care how long it takes. When I get up in the morning, I terminate the analysis. Typically, the engine will be in the middle of a game. I make a copy of the game and then delete all moves already annotated and delete all commentary. That unannotated copy is then ready for analysis the next nite. Later, I merge the two annotated parts of the same game to get a complete annotated game. In scenario (b), there is a trick to speed up the analysis. Let me try to describe this "trick." [This is for use in middlegame and endgame.] I make the engine display multiple lines, typically five or six in the beginning. As the average analysis depth increases up to about 13 ply, I reduce the number of lines [using the - sign on the numerical keypad] so that the only lines displayed are those with evaluations differing by no more than a half pawn equivalent. Then, as the depth increases, I continue reducing the number of lines because the evaluations are beginning to stabilize. Finally, I reduce the number of lines sometimes to one and then let the engine run awhile to bring the depth up to at least 15. If I step away from the computer, as often happens, the depth sometimes gets up to 18 or 20, although that is seldom beneficial. In the above, it is always beneficial to copy the lines to the game score before reducing the number of lines. That is especially important if looking at openings. Here is the "trick": If you are watching, it often happens that there is only one reasonable move. All the other moves have evaluations much worse than the one best move. In that case it's pointless to wait for the engine to go to great ply depths. [No need to progress beyond 13 ply.] Simply select the best move and then go on to the next move. Of course, there is a risk that a good move might be missed this way, but the risk is small. When creating a candidate opening repertoire, it's best to identify lines which seem "not best," because furthur analysis may show that they are best after all. In scenario (c), the display of multiple lines in analysis mode is essential. Doing this avoids missing lines which are almost as good as the "best" line. As noted above, it often happens that these "second best" moves prove to be best after all after deeper analysis. When you force the engine to play YOUR move, it's good to see the different ways that the opponent might respond. I find scenario(c) to be the most personally rewarding. It happens a lot that my moves are good and may not have been analyzed by the engine at reasonable depths. It is great to see one of my moves producing better evaluations than the moves selected by the chess engine! Of course, more often my ideas are immediately refuted. That's life. Maybe someone like Kasparov would find that his ideas were better half the time! I'm not Kasparov. Bob D.
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.