MOO-cows Mailing List Archive


RE: Future of MOO?

>>> 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[] 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.

Home | Subject Index | Thread Index