StupidOS Strikes Again

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Jul 24, 2009.

  1. Lawrence D'Oliveiro

    impossible Guest

    Been there, done that. You're wrong -- get over it.
    impossible, Jul 28, 2009
    1. Advertisements

  2. Lawrence D'Oliveiro

    impossible Guest

    You're a liar.
    impossible, Jul 28, 2009
    1. Advertisements

  3. Lawrence D'Oliveiro

    Enkidu Guest

    Seems to me like you never got past the first multisyllabic word in that
    article. It clearly shows that the RB and SF are marginally useful for
    systems with small memory and useless if the system has a reasonable
    amount of memory.


    Enkidu, Jul 28, 2009
  4. Lawrence D'Oliveiro

    Enkidu Guest

    Fine. You are Lennier and I claim my prize of $100.


    Enkidu, Jul 28, 2009
  5. Lawrence D'Oliveiro

    impossible Guest

    Nah, you're just a liar. Caught out and now twisting int he wind. Bye-bye.
    impossible, Jul 28, 2009
  6. Lawrence D'Oliveiro

    impossible Guest

    If you want to talk in circles, I suggest you ping Allistar. He loves that
    sort of looniness. As for me, I'm done with you.
    impossible, Jul 28, 2009
  7. Lawrence D'Oliveiro

    Enkidu Guest

    In what twisted way can you consider that constituting proof of me lying?


    Enkidu, Jul 28, 2009
  8. Lawrence D'Oliveiro

    Enkidu Guest

    Hah! You don't like being presented with evidence, do you? Buy more RAM.
    Forget SuperFetch and ReadyBoost, which are only of use in low RAM

    You may be interested in this ancient scroll I just uncovered. Maybe
    not, the closed mind can't learn.

    This example from the days, of the dinosaur explains exactly what
    happens in Virtual Memory systems. And guess what - no one has ever done
    any better. SuperFetch is merely a way of guessing which programs you
    are likely to fire up next and pinning them to memory pages. Trouble is,
    if SuperFetch guesses wrong, which it will do, frequently, it takes
    longer to load the requested program into memory. Because SF will have
    preserved the wrong program in memory and the requested one will be in
    swap (slow, slow, slow) or even on the filesystem (even slower) and
    because SF is protecting pages, there will be less free pages available.

    Notice MS themselves don't mention as one of SF's features a reduced
    start up time:


    Enkidu, Jul 28, 2009
  9. Anyway, to cut out all the irrelevant crap and get back to the original
    point: does it really make sense to put the Dimdows pagefile in RAM? Is it
    such a stupidly-designed OS that it cannot make better use of the RAM
    Lawrence D'Oliveiro, Jul 28, 2009
  10. I have some indications that it might be that stupid. I am running 32
    bit Vista with 4 Gibytes of RAM, so my memory meter tells me that I
    have 3326 Mibytes available. Of that, at the moment 976 Mibytes shows
    as being free. But when I just clicked on a tab of the 45 or so I
    have open in Firefox, one that I had not looked at for a couple of
    days, it took ages to display, accompanied by busy disk activity. I
    think that was probably a fair bit of swap activity. So if I actually
    had 976 Mibytes free, why was it swapping?
    Stephen Worthington, Jul 28, 2009
  11. Lawrence D'Oliveiro

    impossible Guest

    You don't have 976Mb "free" -- you're misreading TaskManager (TM is
    confusing, I know, but still ...). You most likely have zero MB
    available -- or something very close to that. Vista allocates every byte of
    available memory -- some to working data and applications (976MB in your
    case), and the rest to the Vista system cache (about 3.3GB - 976MB in your
    case, or roughly 2.3GB). Unlike with past version sof Windows, nothing goes
    to waste in this scheme. But the price you pay sometimes -- as you've
    discovered -- is that Windows isn't all-knowing.

    Vista's system cache is loaded by SuperFetch with the files SF thinks the
    system is most likely to need next.This is based on an ongoing analysis of
    your usage activity (so forget every myth about prefetch you might haver
    mislearned -- **don't delete the prefetch cache**). Problem is, if you've
    left a certain website open for 2 days without viewing it, and you're
    carrying on with other activity on your machine, it's almost certain that
    Vista has shoved that page out of memory and replaced it with something
    else. Hence the delay you experienced.
    impossible, Jul 29, 2009
  12. Lawrence D'Oliveiro

    Enkidu Guest

    It's easy enough to switch SuperFetch off:

    As this article says "In PC with little and barely enough system memory,
    SuperFetch will likely cause memory intensive textures to frequestly
    swap in and out of memory and thrash to disk, slowing the overall
    performance, and in worst case, when using memory hogging software,
    causing out of memory crash error".


    Enkidu, Jul 29, 2009
  13. Lawrence D'Oliveiro

    Enkidu Guest

    Putting the pagefile in RAM is stupid, no matter what OS you use. It is
    simpler and faster, if you have the RAM to use it. If a page gets paged
    out, it is because it is not being used and therefore should not be in
    RAM. If your page is in a RAM based page file you are restricting your
    useful RAM and a page that is required because of a page fault will be
    moved from the RAM based page file to somewhere in the available
    non-page file RAM. This means that the non-page file RAM page has to be
    vacated. So it will either be scrapped or paged out itself.

    If the RAM is used as RAM is intended to be used, it is likely that the
    page would not have needed to be paged out in the first place.


    Enkidu, Jul 29, 2009
  14. Lawrence D'Oliveiro

    impossible Guest

    That's right, just Google for any old dumb thing you can find by people who
    are equal to your level of ignorance.
    impossible, Jul 29, 2009
  15. Actually, there is one situation where putting the pagefile in RAM
    used to be an excellent idea. That was when the RAM installed was
    more than was directly accessible by the CPU. The extra RAM was
    switched with a block of accessible address space using an I/O port.
    Stephen Worthington, Jul 29, 2009
  16. That takes me back. The old RAM disk ! IIRC, you could buy cards for the
    apple II+/e to do exactly that. David Empson would know, David, is my memory
    right here ? :)
    Bruce Sinclair, Jul 30, 2009
  17. Lawrence D'Oliveiro

    David Empson Guest

    (Pokes up head.) Did someone say Apple II? Dredging memory and reading
    thread for context...

    Not specifically to do with page files as in an OS-level virtual memory
    system, but there were many ways to add RAM to an 8-bit Apple II and
    some applications (notably AppleWorks) used their own virtual memory
    system to avoid having to load modules back in from floppy disk.

    Taking the Apple IIe (most common model): the CPU could directly address
    64K, and the computer had 64K of built-in RAM, but some of the address
    space was used for I/O and ROM, leaving 48K of directly addressable RAM.
    Some of the RAM was memory-mapped display, stack, operating system
    storage, etc. which left about 46K for application code and data (in an
    application which didn't need the graphics screen).

    The remaining 16K built-in RAM was accessed by bank-switching out the
    ROM. It contained operating system code and data.

    The Apple IIe usually had an Apple-supplied memory expansion card in the
    auxiliary slot, which added another 64K RAM (128K total). This was
    bank-switched with main memory (in several segments), and mirrored the
    layout of main memory. It was required for later versions of AppleWorks,
    since the code got too big to fit in 48K.

    There were two popular types of larger memory expansion cards:

    (a) Auxiliary slot multi-bank memory expansion cards (from third parties
    only). These extended the concept of the 64K expansion card by adding a
    bank switch register. Due to the bank switching arrangements, it was
    easy to access 47.5K of each bank (via a "copy memory" system call), or
    execute code within that area, but the remaining 16.5K of each bank
    required special support code (since it overlaid stack, zero page or
    ROM/OS). Largest cards of this type had 1 MB of RAM, plus a 2 MB
    piggy-back board.

    These cards were generally only used by software which had special
    drivers (such as AppleWorks), as there was no OS-level support for them.
    Third party RAM disk drivers were available, which required patching out
    the standard RAM disk driver (which used the auxiliary 64K).

    (b) Standard slot memory expansion cards (from Apple and third parties).
    These used a single byte data window and autoincrementing address
    register, so code running in main memory simply copied data to/from an
    I/O location to read or write. These had the nickname "slinky" due to
    the sliding window.

    These cards worked as a RAM disk without installing any software, by
    virtue of having a driver in ROM on the card, and could be used to boot
    the computer. Some had battery backup and/or a separate power supply so
    you could set up the RAM disk for long term use as your startup drive.
    There was also a supported method for an application to reserve part of
    the card for temporary storage. Largest cards of this type were 1 MB.

    AppleWorks had a variety of memory managers, and it picked the best one
    to use based on which memory expansion card you had. (It couldn't cope
    with two memory expansion cards - it just used the biggest one.)

    The Apple IIgs added a further choice to the mix: its processor could
    directly address 16MB and the hardware supported up to 8 MB RAM in its
    memory expansion slot, with a system-level memory manager in firmware.
    AppleWorks added another memory manager module which it used when
    running on the IIgs, that used the IIgs memory manager and ignored other
    memory cards.

    Assuming an 8-bit Apple IIe without an accelerator, reading or writing
    data to a "slinky" card would take in the order of 15 microseconds per
    byte copied in a loop, which was an order of magnitude faster than
    reading or writing a 5.25" floppy (32 microseconds per raw disk byte,
    plus encoding/decoding overhead, seek time, rotational latency).

    This means a virtual memory page file was a huge advantage for a
    computer with floppy disks. It also avoided the need to keep swapping
    disks if using different modules of the application.

    Auxiliary slot memory cards were slightly slower for copying data
    to/from main memory (due to more complex addressing), but had the
    advantage that you could execute code directly in any bank (as long as
    the data it needed was in the same bank). The 16.5K per bank which
    overlaid the OS would have been significantly slower due to needing to
    double buffer everything.

    If you had a reasonably fast hard drive and the controller didn't have
    DMA support, it would have been similar speed to the "slinky" card apart
    from rotational latency and seek time.

    If you had a disk controller with DMA support, it would be substantially
    faster than using a memory expansion card for sequential transfers (just
    delayed by rotational latency and seek time). The theoretical limit of
    Apple's High-Speed SCSI card was 1 MB per second transfer rate (all bus
    cycles used for DMA), but 8-bit software was throttled by OS and driver
    API overhead which meant it could only transfer 512 bytes at a time.

    It probably still worked out faster than a virtual memory system using a
    "slinky" card.

    I doubt AppleWorks tried to second guess your disk controller - it
    assumed that RAM was always better than a physical drive.

    These days people using real Apple IIs tend to use Compact Flash instead
    of SCSI hard drives, but I've been out of the Apple II world for a while
    and don't know how well these cards perform in comparison to a SCSI hard
    drive with DMA.
    David Empson, Jul 30, 2009
  18. Ah ... that's what I remember having.
    I think I had one of those in the gs.

    hmmm .. or maybe it was one of these :)

    (snip) And thanks for that trip down memory lane. :)
    Bruce Sinclair, Jul 30, 2009
  19. Lawrence D'Oliveiro

    David Empson Guest

    Can't have - the IIgs didn't have an auxiliary slot (just standard slots
    and the memory expansion slot). The auxiliary slot only existed in the

    I see from below that you worked out you had a IIgs memory expansion
    card instead.

    The Apple IIc was Apple's first portable, though without a battery, and
    with a power supply brick which had running jokes about weighing almost
    as much as the computer. The IIc had the IIe's auxiliary memory built
    into the motherboard. Late models added a memory expansion slot which
    supported a card that worked like the "slinky" (standard slot card with
    byte-sized window and auto incrementing address register).

    At least one third party managed to emulate a multi-bank auxiliary
    memory card in the IIc by interposing the card between the motherboard
    and the CPU and MMU chips. Installing the card probably required
    removing the plastic backing grid which gave the keyboard rigidity.

    I took that plastic grid out in one IIc in order to install a Rocket
    Chip accelerator (ooh, 5 MHz!)
    You're welcome.
    David Empson, Jul 30, 2009
  20. Lawrence D'Oliveiro

    Enkidu Guest

    It's what 'impossible' and his ilk will never understand. Way back in
    the days of DOS we were building RAM disks to pre-load applications that
    we wanted access to fast, and were prepared to give up memory for. Now
    Windows 7 grabs a part of your RAM to pre-load applications that you
    want access to and call it an amazing new advance.


    Enkidu, Jul 30, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.