Computer Chess Club Archives




Subject: Re: is the

Author: Ernst Walet

Date: 23:37:19 07/29/98

Go up one level in this thread

On July 29, 1998 at 17:22:29, Komputer Korner wrote:

>On July 29, 1998 at 10:38:10, Ernst Walet wrote:
>>On July 29, 1998 at 08:08:01, Komputer Korner wrote:
>>>On July 26, 1998 at 17:42:50, Bruce Moreland wrote:
>>>>On July 26, 1998 at 10:46:14, Komputer Korner wrote:
>>>>>Two copies of the hash table must get loaded. One temporarily because whenever
>>>>>you exceed 50% of the RAM (fritz 5 is an exception because they create a
>>>>>separate process for the engine and hash table) every chess program thrashes
>>>>>with swapping. After the swapping stops then you can continue.
>>>>No.  This is just fundamentally not how things work.
>>>>> As for WIN 98 the
>>>>>problem is solved only if a new program is written  in inline blocks of code.
>>>>>The problem will continue with all the old programs.
>>>>What ??
>>>"Current Win 95 versions load programs by first copying the executable file into
>>>disk cache memory, as shown in "Windows 95, Windows 98 Unaligned." From there,
>>>the OS copies the one or more program modules in the file to another block of
>>>memory, aligning each on a 4-kilobyte page boundary required by the virtual
>>>memory manager.
>>>You'll actually see two copies of the program in memory just after it's loaded.
>>>One copy is in the disk cache, the other is in the memory where it will be run.
>>>Over time, other disk activity in the system will cause the copy in cache to be
>>>discarded. But when a program starts, it essentially uses an amount of memory
>>>twice the size of the program.
>>>In Win 98, Microsoft has found a way -- in certain cases -- to eliminate the
>>>double-memory penalty while loading programs. If the program code is already
>>>aligned on 4-KB boundaries when it's loaded into the cache, Win 98 runs the code
>>>directly from the cache, as shown in "Windows 98 Aligned." (Windows won't
>>>discard the file from cache as long as the program is running.) That not only
>>>saves the extra memory that would have been used, it also saves CPU time because
>>>you don't have to copy the data between two locations in memory. In the future,
>>>Microsoft can simply advise vendors that aligned code runs faster, and vendors
>>>can align upcoming applications before they're shipped.
>>>Nearly all the code that exists today is unaligned, which means you won't likely
>>>encounter the optimized case until newer applications start to arrive. So
>>>Microsoft developed a utility called WinAlign that will automatically align
>>>existing code files. There are some compatibility issues with changing existing
>>>code files, though, so WinAlign changes only those files that have been tested
>>>and are known to work once they're aligned. The most important among those is
>>>probably Microsoft Office; both the 95 and 97 versions will be aligned if
>>>they're found during installation.
>>>FAT32 is an important part of the improved memory management and program load
>>>times because the 4-KB cluster size of FAT32 disks matches the 4-KB page size
>>>the virtual memory manager uses. FAT16 disks usually use 32-KB or 64-KB cluster
>>>sizes. Because cache is managed on a cluster basis, there's a greater chance in
>>>a FAT16 disk the data read won't be needed, and the time and memory spent
>>>reading the data will be wasted."
>>>If the hash table isn't duplicated then why do all the programs except Fritz (
>>>and even Fritz sneakily disallows more than 50% of RAM for hash tables) swap to
>>>the hard disk whenever a hash table larger than 50% of RAM is used? So either
>>>Windows 95 is grabbing the available RAM for itself or 2 copies of the hash
>>>table are temporarily loaded. I notice that with  DOS chess programs with WIN
>>>95, the effects of swapping aren't temporary. If you load 60 or 70 % or more  of
>>>the RAM for hash tables, you will get swapping on every move.  Shredder 2 won't
>>>even allow swapping. It just refuses to start when more than 50% of RAM is used
>>Not true, with 48MB RAM you can easely use 32MB (24+8) hash.
>>>for hash tables. Fritz 5 is interesting. In the hash table dialog box you can
>>>enter 90% of the RAM for hash tables in WIN NT 4 but in the Task Manager, you
>>>can see the real amount allowed in the ntvdm.exe shell that manages all the
>>>Fritz processes. With 144Mb of RAM and a single Fritz engine it allows only 69
>>>Mb of RAM to be used. With engine vs engine, it goes to 78Mb RAM total for all
>>>engines even when I load 60Mb each!!!!!!!!!
>>Not true either, with 48MB hash you can use 40MB hash, altough you'll get
>>swapping the fist few minutes.
>>>Komputer Korner
>Your comment about Fritz using 40Mb hash may not be true. No matter what hash
>figures show up in the Fritz hash dialog box ( Fritz actually adjusts these
>numbers itself) are not what is really used in the program. To see this you must
>use something like WIN NT 4's task manager which shows the real picture.
>Komputer Korner

With WIN95 System Monitor you can accomplisch the same, by looking at the
allocated memory minnus the disk cache size.  And this is waht I did.


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.