Author: Komputer Korner
Date: 14:22:29 07/29/98
Go up one level in this thread
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
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.