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