Computer Chess Club Archives




Subject: Re: is the

Author: Ernst Walet

Date: 23:49:54 07/29/98

Go up one level in this thread

On July 30, 1998 at 02:37:19, Ernst Walet wrote:

>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.

To make things easier to detect, I limited the vcache size in the system.ini


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.