Author: Komputer Korner
Date: 06:46:06 07/30/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. This is just not true. See below. Nimzo 98 takes up to 106Mb for a hash table in WIN NT on my 144Mb system. Nimzo 3.5 takes up to the same amount in WIN 95 if you have 144Mb of RAM and without swapping. However on a system with only 40Mb of RAM, one cannot load more than about 18 Mb of RAM for a hash table in Nimzo 3.5 without terrible swapping on every move. Thus WIN 95 must grab about 20Mb of RAM for itself when it forms it's page file. The WIN 95 System Monitor is a sorry excuse for a reporting tool compared to the WIN NT 4 Task Manager but here are the findings after starting WIN 95 and Nimzo 3.5 on a system with 144 Mb of RAM.Allocated memory- 161.7Mb Free Memory- 16KOther Memory- 42.4 MbSwapfile Size - 18.5 Mb Swapfile in use- 2.7MbDiskcache size- 23.7MbLocked Memory- 27.4 Mb Swapfile defective- 0Swappable memory- 119.2Mb Now if anything is more confusing than this I haven't seen it. So if we take your equation we have 161.7Mb- 23.7Mb = 138Mb for a hash table which is NOT TRUE. The WIN 95 System Monitor is brain dead or else the entries mean somethimg else than what they read. That is one of the reasons why I like to stay in the WIN NT 4 environment. After shutting down Nimzo 3.5 , the amounts of the above table change to the following:Allocated memory-55.2MbFree Memory- 105.2MbOther Memory- 42.3Mb Swapfile Size - 2.7MbSwapfile in use- 2.7MbDiskcache size- 23.6 Mb Locked Memory- 26.9 MbSwapfile defective- 0Swappable memory- 12.8Mb When I shut down WIN 95, and restart the numbers there are very small changes in the numbers except that Swapfile size and Swapfile in use drop to 0 and Free Memory drops to 102.2 Mb. So it is all very confusing but it seems that unless you limit the vcache size in Windows system.ini WIN 95 will take some of your precious memory for itself. It seems that from the Free Memory numbers, WIN 95's system monitor doesn't know what the hell is going on. Maybe nobody knows. We do know that if you limit the vcache, some other input-output operations will be drastically affected so that isn't a satisfactory solution. But what is clear is that this drastically limits systems with smaller amounts of memory.ie: Systems with less than 64Mb of RAM. On my other WIN 95 system with 40 Mb of RAM, the amount of RAM clearly isn't enough. Perhaps some programs round up to the next hash table size instead of rounding down and that would help to explain what happens (massive swapping)when I try to create 20Mb hash table or more on my system with 40 Mb of RAM. -- 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.