[MUD-Dev] Re: Re: MUD Development Digest

[J C Lawrence]

From: "Dr. Cat" <cat at bga.com>
Message-Id: <199804042149.PAA27614 at zoom.bga.com>
Subject: Re: [MUD-Dev]  Re: MUD Development Digest
To: cynbe at muq.org (Cynbe ru Taren)
Date: Sat, 4 Apr 1998 15:49:08 -0600 (CST)
Cc: cat at bga.com, claw at under.engr.sgi.com
In-Reply-To: <199804041745.LAA07123 at laurel.actlab.utexas.edu> from "Cynbe ru Taren" at Apr 4, 98 11:45:05 am

> For the most part -- but remember that even if you're not paging
> within the disk/ram portion of the memory hierachy, you're probably
> still paging between ram/cache2 and cache2/cache1:  Better locality
> of reference will still improve performance there.
> 
> A fundamental win of a disk-based system comes from clustering
> data used together in ram, which improves performance at all
> levels of a hierarchy.
> 
> A viable alternative is to do the same thing entirely in ram -- a
> copying garbage collector, for example, can have this effect.  Well
> done, on ram-poor systems this can result in entire pages full of
> unused objects paging out to disk, yielding an effectively disk-based
> system without the explicitly coded disk I/O.

It sounds like you're still talking about a system that does a lot of 
dynamic allocation of stuff and/or moving things around in RAM.  While 
that's probably true of most mud servers, it's not the case in mine.
I hadn't really thought much about CPU caching issues, but I'm probably 
pretty well off there.

Anyway it seems to me that either a RAM based or a disk based system 
could happen to have things arranged well for the CPU cache, or poorly.  
If it's important, either of them could be recoded to make things more 
optimum.  It does seem to me that writing things out to some slow 
physical device that has to spin stuff around with a motor, and then 
reading them back in again, because this coincidentally arranges them in 
a way that the CPU cache likes better...  That sounds like a pretty 
bizarre way to go about things!  I guess if it's a way that programmers 
can get results without doing high quality professional level code 
optimization, it's useful for some people.  If I generated garbage, I'd 
rather write the garbage collector in RAM though.  Designing my system 
to not generate garbage I find even more preferable.  :X)

Anyway a commercial system that generates any significant amount of 
revenue per users at all ought to be able to afford a decent amount of 
RAM per user.  So I'm not too worried about it.

*-------------------------------------------**-----------------------------* 
   Dr. Cat / Dragon's Eye Productions       ||       Free alpha test:
*-------------------------------------------**  http://www.bga.com/furcadia
  Furcadia - a new graphic mud for PCs!     ||  Let your imagination soar!
*-------------------------------------------**-----------------------------*

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

--
MUD-Dev: Advancing an unrealised future.