[Home] [Groups] - Message: [Prev in Group] [Next in Group]
6737: Re: [MUD-Dev] Re: MUD Development Digest
[Full Header] [Plain Text]
From: "Jon A. Lambert" <jlsysinc@ix.netcom.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 9 Apr 1998 01:51:35 -5
References: [1]
Organization: Kanga.Nu
On 8 Apr 98 at 13:33, J C Lawrence wrote:
> On Sat, 4 Apr 1998 09:39:55 PST8PDT
> Justin McKinnerney<xymox@toon.org> wrote:
>
> > First, I agree with your first comment. I have heard people claim
> > their disk-based muds run faster than memory-based, but this all
> > semantics. If a disk-based game does run notably faster than it's
> > memory-based equivilant, it's simply due to the fact the operating
> > system is doing a better job of memory managment (perhaps doing
> > cache alignment, for instance), which wouldn't be suprising
> > considering some of the code for MUDs I have seen.
>
> No. Typically it has nothing to do with the OS'es memory supports,
> but has to do with working __around__ the OS'es memory model as it
> is inefficient for the task at hand. The performance gains are due
> to the fact that the disk-based game uses intelligent cacheing which
> forces a (reasonably) minimum number of pages for the game's working
> set. Its not very difficult to put the entire world in RAM, and
> then chew all your performance with page faults -- or to get it back
> again by keeping some of the disk IO, but losing the constant page
> faults.
Speaking of page faults... there are issues of implementation which,
if transgressed often enough, make for some bottlenecks in this area
outside of the disk vs. memory issue.
For example:
This will cause 5000 page faults...
for (col = 0; col < 1000; col++)
for (row = 0; row < 5; row++)
table[row , col] = 0;
And this about 5 page faults
for (row = 0; row < 5; col++)
for (row = 0; col < 1000; row++)
table[row , col] = 0;
The same scenario also occurs in good size link lists, where the
objects have been allocated haphazardly by a fiendish malloc().
There are many possible solutions. I grab a hefty chunk of memory,
mark it unswappable and stay within that playground. Then page out
unreferenced or least-referenced objects to disk as needed. You CAN do
a much better job at application memory management than the operating
system can.
--
--/*\ Jon A. Lambert - TychoMUD Internet:jlsysinc@ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--