[DGD] Re: DGD vs. MudOS

[Felix A. Croes]

George Reese <borg at imaginary.com> wrote:
> Kevin Carpenter wrote:
>[...]
> > 4) MudOS is a collective project (or at least it was) written by many
> > people over many years.  As such, there is often several ways, often
> > with several side-effects, to do even simple things like writing a
> > message to a user.  Having Felix be the sole driver maintainer results
> > in a clean driver.
>
> Messaging is an extreme example.  While DGD is a cleaner driver in terms
> of code, that only really effects people who want to modify the driver. 

I believe that Kevin was talking about the "cleanliness" of the kfun
interface, rather than that of the C code that DGD is written in.
I also believe that this interface makes a great deal of difference --
to the mudlib designer.


> > 5) With 20-40 people logged in, admitted only conversing, not do any
> > CPU intensive things like combat, my mud consumes about 3% of my 120Mhz
> > 486.  I don't really care if MudOS is marginally faster processing some
> > implementation detail.
>
> I agree here.  The relative processing speed of both drivers is
> irrelevant.  They are both fast enough.  Pick the one that suits your
> other needs.

They are both fast enough, now, for current typical usage.  This may not
always be so (see below).


> > Don't be concerned with DGD being "disk based".  That adds flexibility,
> > and would only become a performance concern under weird conditions
> > (like you having a 10mb mapping that you routinely scan, but only
> > have 5mb of memory for the mud).  My log file IO rate is probably
> > an order of magnitude higher than my swap file usage.  The only
> > problem I've had is that it can take some time to write out a dump
> > file, if you want to restart later.  I've had some problems with
> > getting a test version of the mud to do this within the normal UNIX
> > shutdown period.
>
> Log file I/O can be reduced by going MT with log I/O.  Beyond that, I do
> think being disk-based is a disadvantage if you have the RAM.  It is a
> bonus if you do not.

Both Kevin Carpenter and George Reese make assumptions here about
the amount of memory that a mud should typically need.  It is true that
current machines tend to have a lot more memory than 4 years ago, when
I first released DGD to the internet.  But there is no reason why the
software should not grow with the hardware.  The desire to deal with
muds whose size measures in gigabytes or terabytes, with tens of
thousands of users online simultaneously, is what motivates me in making
DGD multi-threading for multi-processor systems.  In those ranges,
having the mud to be disk-based is still an advantage today.

Aside: it is entirely possible to configure DGD for no swapping.

Regards,
Dworkin