Computer Chess Club Archives




Subject: Re: is the

Author: Roberto Waldteufel

Date: 03:42:09 07/30/98

Go up one level in this thread

On July 30, 1998 at 06:08:06, Robert Hyatt wrote:

>On July 29, 1998 at 23:54:33, Roberto Waldteufel wrote:
>>On July 29, 1998 at 10:08:11, Bruce Moreland wrote:
>>>On July 29, 1998 at 08:08:01, Komputer Korner wrote:
>>>>"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.
>>>[rest of quote snipped]
>>>This is talking about how the executable file is loaded into RAM.  This would be
>>>done before the first instruction is executed, obviously.
>>>I don't know a lot about this, but this sounds like a boot-time issue that
>>>wouldn't mean very much, especially on a computer with sufficient RAM. The EXE
>>>will probably be under a megabyte, they'd just read it into the disk cache,
>>>allocate a new block, and copy it into the new block.  *Then* the app gets to
>>>run, and allocate its hash table, and do the other nasty things that chess
>>>programs do.
>>>We're talking about small amounts of memory here, during the earliest phases of
>>>application boot.
>>>>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.
>>>This is just wrong.  The thing you quoted talked about an inefficiency involved
>>>in taking a file off the disk and turning it into something that could be
>>>executed.  Something is read from disk, diddled, then copied into a new memory
>>>There is nothing that would point to something more sinister -- that every
>>>memory allocation would be done twice, or that anything that is read from the
>>>disk involves two memory allocations somehow.
>>>The most major deviation from reality in what you say involves the word
>>>"loaded".  You can talk about an EXE being loaded, but it doesn't make any sense
>>>to talk about a hash table being "loaded".  A hash table is allocated, not
>>>loaded.  You request memory from the operating system and it gives it to you.
>>>The minor problem you mention, involving the exe being loaded twice, is a higher
>>>level issue than this, and it is easily understood by anyone via the quote you
>>>included.  This other problem you contend exists would involve the memory
>>>allocator being fundamentally broken, for no conceivable reason, and in a manner
>>>that has no conceivable relation to the other problem.
>>>I don't know what design decisions Fritz made regarding their hash table, but
>>>let's discuss this for a moment.  You have a chunk of memory that will be
>>>accessed randomly (meaning at an unpredictable point) several hundred thousand
>>>times per second.
>>>This is basically a tub of anthrax waiting to kill everyone.  When I was in
>>>college we had this cheesy HP 1000 minicomputer that ran BASIC and nothing else,
>>>and that is how we all learned how to program there.  You could do a lot of cool
>>>things in that BASIC, but it was pretty hard to destroy the computer.  In early
>>>1984 we got a brand new Eclipse MV/10000, with an incredible amount of disk and
>>>RAM (a gig of disk and six megs of RAM).  This only cost about a half million
>>>dollars.  It had virtual memory, and we very quickly discovered that we could
>>>slag that machine by simply writing something that allocated more than six
>>>megabytes of RAM and then accessed it randomly.  The machine wouldn't crash, but
>>>it would freeze until the OS figured out that someone was being a jerk, at which
>>>point it would prevent that application from stealing pages from other
>>>applications, which would cause it to sit there in a little cell, eating its own
>>>flesh like crazy, and not annoying others very much.  But this was annoying at
>>>the start, because it took the OS like 30 seconds to figure it out, during which
>>>time everyone was looking around going "What! Is the machine crashed?", and when
>>>the thing came back it took everyone by surprise and their snakes crashed into
>>>the wall and they had to start a new game.  Bummer.
>>>My point is if the hash table is too big, you get thrashing that is beyond
>>>anything that the machine can handle.  So the tendency is to not allow the hash
>>>table to get too big, and that is probably what Fritz did here.  They don't want
>>>to get into conflict with the OS and they don't want to get into conflict with
>>>other applications, so they play it safe.  It is exactly what I would do as
>>Hi Bruce,
>>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. This is not what I bought my extra RAM
>>for. So how can I load and execute a program entirely in RAM, with all its data
>>in RAM, with no disk access, no multitaskink, no fancy bells or whistles, just
>>maximum speed and efficiency? Is there an operating system that allows this?
>>Sadly my computer came with Windows95 installed, which is fine if you want an
>>office machine to do lots of things at once, but I don't need that. I'd much
>>rather have something simple but efficient, akin to the old DOS, but with 32-bit
>>mode operation and access to all the RAM without all the headaches that came
>>with addressing above the first megabyte.
>>Best wishes,
>one solution is to go to NT.  95 is simply too brain-damaged to do well here.
>I haven't had a chance to try 98 yet, so I don't know if it was improved in this
>respect or not.  But NT works exactly like you'd expect it to (very similar to
>unix here)...

Thanks - I'd do almost anything to get control over all my RAM. If I had only
known how cr**  Windows95 was - at least for my purposes - I could have ordered
NT at the outset. Is it a fairly painless affair to upgrade, or are there
problems running 95 programs under NT? I can't hep being a little suspicious of
anything from Microdoft after my unfortunate experiences with Windows95. There's
another thing that is also annoying - Windows 95 seems to crash for no apparant
reason periodically. It can't be just a fault in my program, because the same
thing happens sometimes with all kinds of other unrelated applications.

Best wishes

This page took 0.01 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.