Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: is the

Author: Bruce Moreland

Date: 06:11:11 07/30/98

Go up one level in this thread



On July 29, 1998 at 23:54:33, Roberto Waldteufel wrote:

>Well, here's the big question. I spent a lot of money on a fast PC with 64MB of
>RAM for the main purpose of developing a chess program. I specially had a 64 MB
>machine rather than 32, which was standard, because I wanted to use at least
>40MB for hash tables, maybe more. Now I get all this terrible swapping. I have
>even tried writing an entry in each hash table position before the program
>starts play, which gets a lot of the swapping done in advance, but still some
>occurs during the early part of the game.

On all my machines I run with a 48MB hash table, not because I think it will
thrash at 96MB, but because I know I won't have any problems if I am running the
debugger, an internet browser, excel, agent, exchange, and whatever else I can
think of, all at the same time.

When I start mine on NT, it just goes, but NT is supposedly piggier than Windows
'95.

I have another machine that runs Windows '95.  It is a P2/300 with 128 megabytes
of RAM.  When I restart this machine and start my chess program it just goes,
same as on NT.

But I do have times, probably after I've run all of the stuff I mentioned above
with the possible exception of the debugger, when I get this long pause at the
start, maybe ten seconds, during which the disk light is going constantly.  This
is before I have started to calculate anything.  I know this because I still
have an hourglass cursor.  Once I get past this I am fine.

Remember though that my hash table is only 48MB.  So it's not like I'm taxing
the machine too much.  I have no idea what it is doing during that time though.

Regardless, I don't think it should matter for development purposes big your
hash tables are.

bruce



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.