[Prev][Next][Index][Thread]

# RE: Future of MOO?

- Date: Thu, 27 Feb 1997 18:48:15 PST
- From:
- Encoding: 57 TEXT

    >>> will there ever be a diskbased version
    >>> and are diskbased and fast?

    At 02:22 PM 2/27/97 PST, Jay Carlson wrote:
    >What does this term "diskbased" mean?
    >What problems does it solve?
    >How does it interact with the goal of "fast"?

    Brack[SMTP:slayer@kaiwan.com] replies
    >why I'm answering this I don't know....
    >By "diskbased" she meant that the MOO would run off the disk like many
    >MUDs do, rather than running off a copy of the database in RAM.
    >This would solve the problem of needing enormous amounts of RAM just
    >to run a MOO. By "fast" it would mean less swapping (if any) would be
    >required and more RAM would be freed for the machine to use.

    Since most machines these days use virtual memory and disk I/O caches,
    the line between "running off the disk" and "running entirely in RAM" is
    rather severely blurred.  It is the fundamental nature of virtual memory
    that, once you request more memory than you physically have, you are, to
    some extent, running off the disk whether you like it or (more likely)
    not.  Conversely, a program that "runs entirely off the disk" may yet be
    running mostly in memory if its pattern of disk accesses is suffiently
    I/O-cache-friendly (i.e., not trying to touch so much of the disk at
    once that it blows out the cache).

    The real issues as I see them are

    (1) performance, i.e., what performance win is to be had by having the
    server take more explicit control over the disk

    One would think that since the server has some concept of how often
    various objects/slots are used, it could implement its own swapping with
    somewhat more intelligence.

    Then again, given how generic the MOO language is and how much work has
    gone in over the years into OS paging algorithms and the fact that the
    OS-level stuff has a fair amount of hardware support, even having a
    server that will do as good a swapping job as the OS would have done
    will be something of a challenge.  It may be that the effort would be
    better spent restructuring the memory layout of MOO code/data so as to
    be more paging-friendly, thus working *with* what the OS has already
    provided rather than trying to reinvent/duplicate it.

    (2) how best to achieve persistence

    The ideal here is that the state of the world should be continually
    saved in as low-overhead a manner as possible and that restoring this
    state (i.e., when your server crashes) should go as quickly as possible.

    I think there's a fairly strong consensus that forking every n hours to
    do a disk dump is not really the best way to do a checkpoint.  I also
    suspect that this, fast incremental checkpointing and fast
    restore/startup, is really what people are concerned about when they say
    they want a "disk-based" server.  The actual implementation that
    achieves this is immaterial.

- Prev: Re: Future of MOO?
- Next: Re: Future of MOO?
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index