Author: Scott Gasch
Date: 13:09:41 01/16/03
Go up one level in this thread
On January 16, 2003 at 15:41:16, David Rasmussen wrote: >On January 16, 2003 at 15:25:19, Dieter Buerssner wrote: > >>On January 16, 2003 at 13:31:39, David Rasmussen wrote: >> >>I have not read all the answers carefully, so sorry when I repeat some points. >> >>For me, OS cache seems to be more important, when heavily probing TBs than the >>Nalimov-Cache. Access in the Nalimov-Cache is of course faster, but more space >>(a major factor) is needed, to cache the same number of positions. So, >>especially in heavy TB-probing situations, it will be useful, if you have a big >>ammount of free RAM, that the OS can (and will) use for cache. >> > >I only have 256MB RAM in this machine. That might be part of the problem. If >that is the problem, is there anyway to confirm it? I guess I could look at the >Windows Task Manager performance tab, and see how much cache is used, or >something. Assuming you are running XP/2k take a look at perfmon.exe. I suggest you have a look at the following counters: Process | Page Faults/sec (for yourengine.exe) Process | I/O Read Bytes/sec (for yourengine.exe) Process | Working Set Process | Private Bytes Cache | Fast Reads/sec Cache | Fast Read Not Possible/sec Cache | Read Aheads/sec Memory | Page Faults/sec One theory: Your OS is under memory pressure (how many bytes free when you are running your engine in a normal position) and has reduced the working set size of yourengine.exe to compensate. The part that it paged out is your EGTB cache because "well, yourengine.exe doesn't seem to be touching this memory, let's trim". Everything is fine when you are playing non endgame positions but as soon as you get into an endgame you start probing. That is I/O to the EGTB files but also the EGTB code suddenly wants to touch the EGTB cache. Well the kernel is now taking page faults and swapping in the EGTB cache. Double whammy. I don't suspect cacheman performance as a culpret here, I am more inclined to suspect memory pressure and working set trimming on a 256Mb machine. You want your engine to be taking VERY VERY few page faults if any while searching. Personally I lock my transposition table into main memory and tell the OS do *not* swap any of this. See VirtualLock on windows. You need admin privileges to do this and you may have to call SetProcessWorkingSet before the call succeeds. You might try locking your EGTB cache into memory as well if you find that yourengine.exe is taking a lot of page faults while probing. Just an idea. Good luck. Scott > >>Another thing - don't install all TBs. If your engines has problems with missing >>promotion cases, you must be careful to select them. Don't define T41_INCLUDE. >> > >What is T41_INCLUDE? >Also, I have _all_ 3-5 TBs, all 7.1GB of them. That's ok, isn't it? Also, I >don't understand what you mean by problems with missing promotion cases. > >>Don'T forget to hash TB-positions. You can flag them somehow, so that they will >>be good for a cutoff at any depth. >> > >I store them as exact with maximum draft. But maybe I will check later if I have >a bug that somehow causes these not to be stored, or not to produce a cutoff >when re-encountered. > >/David
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.