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 ?? >>>>> >>>>>bruce >>>> >>>>"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 >>> >>> >>>Ernst-Jan. >> >> >>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. > >Ernst-Jan. To make things easier to detect, I limited the vcache size in the system.ini Ernst-Jan
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.