[MUD-Dev] about MOO

[Jay Carlson]

Dan Root (dar at thekeep.org) writes:

> In message <199911201824.KAA31012 at portland.puremagic.com>,
> bruce at puremagic.com writes:

> Indeed, but as you mention below, one of MOO's strengths is that it's got
a
> rather large base of people who know the internal coding language and have
> a fair grasp of how the system works overall.

Reasonable-sounding proposals for changes to the mainline MOO language often
founder on two design criteria:

1) They must not require beginners to learn complex things to produce
reasonably correct code.  Fancy security models, mutable values, and
programmer-visible multithreading fail this, even though they appeal to the
CS weenie in all of us (even the ones saying no!)

2) You Must Not Break LambdaCore.  Or JHCore.  A naive linecount of JHCore
and the C server source shows JHCore winning, 47kloc to 36k.  This is just
peanuts compared to LambdaMOO itself, at ~900kloc.  Sure, a lot of
LambdaMOO's code is just cut&paste, but you'd still have to check it.  So
any semantic changes that require manual review of any decent fraction of
this code are just right out.  Oh, and I'm not counting any non-code object
components in this; if changes in the language required significant code
changes, there'd also be a lot of documentation to rewrite.  And then
there's LambdaMOO politics and accounting to consider as well---this has
significantly complicated lightweight object proposals.

These two rules have, for good or ill, promoted the development of a large
programmer base at many levels of expertise.

> >As for nothing being written in MOO that would be impacted by switching
to
> >a disk-based mechanism, I think that would probably prove to be incorrect
> >if you were aiming for a high-performing system.  Keeping trace of the
> >size of your cache (in your head as you design), and how the object
access
> >patterns you are creating will load or unload large amounts of objects is
> >importnat to do.  If you have a system that requires a large number of
> >objects to be loaded to read some properties from them, or to execute a
> >method on them, you'll be creating a lot of disk I/O and will slow the
> >system down.  Imagine getting a index of mail messages in a mail folder.

If you manage your cache in terms of the number of objects loaded into it,
you will lose badly.  Object sizes vary wildly.

> CoolMUD's database does this, and seems to do a pretty decent job.  That
> said, more than something like a mail index, the place you'll lose most
> heavily is on MOO's inheritence.  Most game cores (Lambda and JHM both
> suffer from this) have a fairly deep and sometimes rather broad object
> inheritance trees.  It's possible to have a siginificant portion of your
> cache filled with nothing but items that are inherited in your active
> objects.

On LambdaMOO, there are only ~2300 objects with children out of ~80k.  That
doesn't seem that excessive to me.

> OTOH, it's certainly possible to cache quite a bit and still see a
> significant reduction in active memory usage.  LambdaMOO was using upwards
> of 256 megs of memory at one point, and I'm sure that number isn't going
> down.

The LambdaMOO machine has 256M of physical memory.  The highwater process
size sits somewhere between 330M and 360M, depending on how fragmented it's
gotten.  The initial highwater mark is misleading, because there's some
bookkeeping done during db load that's free'd in one big chunk before the
server starts running.

Memory usage went down as of about a year ago due to some hacks Ben and I
did.  The size of the database, which is otherwise *roughly* correlated with
memory size, is held constant by various population control measures.

I don't have any good figures on what the working set is for a given time
interval.

> If even 1/10th of your objects were simultaneously active, and that
> many more needed for the inheritence of the active objects, that's still
> reducing your active memory image by nearly 4/5ths.

But *which* 1/10th?  Again, object sizes vary wildly.

Anyway, all other things held constant, reducing LambdaMOO's memory size by
4/5 this way would be a *lose*.  The machine has a certain amount of
physical memory, and treating the 200M freed up this way as merely disk
buffers to thrash objects in and out of by expensive marshalling and
unmarshalling seems...unproductive.  The only win I can see is improvement
in locality, but you could lose that too if you weren't really careful.

I know, the point is not to hold all other things constant :-).  But once
that restriction is lifted, I'd just go get a ~$3k 512M dual P2/450 to
replace the SC1000 it's running on now and see what happens before spending
any more sleepless weekends working on performance.

> Cool and MOO's languages are not quite identical, but close enough that
> anyone using one can use the other, more or less.  The primary differences
> are around the features of the languages.  Cool has tables/dictionaries,
> which MOO doesn't, so MOO makes up by having some more powerful list
> manipulation features instead, as an example.

The mainline MOO server is getting dictionaries merged in in the near
future.

> Lacking a good core DB is definitely a problem for many game drivers out
> there, Cool being no exception.

LambdaCore and JHCore are the big reason I never switched over to Coldmud
development after being heavily involved with the initial design.

Jay




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev