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 >>>block. >>> >>>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 >>>well. >>> >>>bruce >> >>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, >>Roberto > > >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 Roberto
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.