Author: Robert Hyatt
Date: 05:52:47 07/30/98
Go up one level in this thread
On July 30, 1998 at 06:42:09, Roberto Waldteufel wrote: > >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 Win95 has *not* been a good product, although it has certainly made Microsoft a lot of money. But it does crash. My wife uses it here at home, and at least once per night has to reboot because it hangs, or the network stuff (PPP) suddenly quits working, or an application crashes, etc. NT is not trivial to convert to, although a chess engine should have no problems at all. But the GUI might. And not every program that runs under win95 will work under winNT. So if you have some favorite non-Microsoft piece of software, you might well find that it won't work. But the conversion is well worth the trouble, because we have NT machines that have been up for months at a time. We never had a win95 machine stay up for a whole day in our labs...
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.