Author: Komputer Korner
Date: 22:13:05 05/28/98
Go up one level in this thread
On May 28, 1998 at 23:26:37, Komputer Korner wrote: >On May 28, 1998 at 13:19:08, Ulrich Tuerke wrote: > >>Meanwhile, I have a very natural explanation for the observed problem. >>KK has probably overdone with the hash tables. From the debug data, I >>have seen that Crafty had allocated 53 MB hash tables and Comet 32 MB. >>I guess, this was too much for the platform the match was running on. >>On platforms with virtual memory management (like WIN-32), processes >>will be swapped out to the hard disk when shortages of memory occur. >> >>Assumed that the Comet engine had been swapped out of the memory in >>the moment where Crafty was resigning, then it could take seconds to >>reload the program and may be winboard's timer had the chance elapse. >>May be some of the users don't realize how dangerous it is for a chess >>program to overdo with the hash tables. It's better to allocate less >>to be on the safe side. >> >>Regards, Uli > >The above is false. If you check the Comet.ics file you will see 48Mb of >hash for Comet. I can't help it if Comet doesn't have pawn hash tables. >So this match up of 48 Mb hash for Comet and 48Mb main hash + 5 Mb for >pawn hash tables for Crafty is fair. I am testing on a WIN NT 4 system >with 144Mb so nothing is getting swapped to the hard drive. >-- >Komputer Korner I checked the log file of Comet. I guess it must have a limit of 32Mb hash table. I gave Comet 48Mb not knowing that the limit is 32Mb. I will change Comet's hash table size. However I have 144Mb of RAM in a WIN NT 4 system. WIN NT 4 unlike WIN 95 DOES NOT load 2 copies of the same application including hash tables every time into memory ( one into cache and the other into main memory). WIN NT 4 does not do this so you can run programs like Nimzo 98 and Crafty which will take all the hash RAM you can give it in WIN NT 4 without disk swapping. In WIN 95, you have to limit the hash tables to less than 50% of the RAM. Fritz is an exception. It does not have this problem in WIN 95 because it has extension modules that load as separate processes for the engines. They somehow get around the WIN 95 problem of loading 2 copies of a program. So my system and setup is not the cause of these timing problems. One simple solution would be for every engine programmer in Winboard not to send a move before the engine resigns, instead the engine should just resign if it is going to resign.
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.