[MUD-Dev] New Beginings

[David B. Held]

From: "Bruce Mitchener" <bruce at cubik.org>

> The discussion of how the Orbitz system used Lisp as given by Paul
> Graham is interesting as well:

Yes, and I didn't think about this thoroughly enough last night, or
I would have pointed out some obvious things which I shall point out
now.

>      "4. Because we have about 2 gigs of static data we need rapid
>      access to, we use C++ code to memory-map huge files
>      containing pointerless C structs (of flights, fares, etc),
>      and then access these from Common Lisp using foreign data
>      accesses. A struct field access compiles into two or three
>      instructions, so there's not really any performance. penalty
>      for accessing C rather than Lisp objects. By doing this, we
>      keep the Lisp garbage collector from seeing the data (to
>      Lisp, each pointer to a C object is just a fixnum, though we
>      do often temporarily wrap these pointers in Lisp objects to
>      improve debuggability). Our Lisp images are therefore only
>      about 250 megs of "working" data structures and code.

Here, we see illustrated my point that in many GC languages, you
have no way to turn off GC, which is why these guys resorted to
building the data structs in C/C++.  And in this case, they realized
that GC would be a major performance hit, because even though the
static memory would never be reclaimed, references into it would be
constantly checked by the GC.  In C++, of course, you could still
use the same GC if you liked, yet have the flexibility to create
non- collected objects all in the same program, without having to
resort to other languages.  They clearly had reasons to use Lisp,
and I don't question those reasons, as they are probably very good.
But in this case, the GC got in the way, and they had to work around
it.

How does this relate to MUDs?  Well, text MUDs often load up area
files into memory using a read-only shared string space.  This is
just like the static data in the Orbitz example.  You wouldn't want
a GC to look at references into this space, because you aren't going
to reclaim it until you shut down.  So, in a GC language, you have
to be aware of this "feature", and circumvent the GC in some way to
keep it from constantly looking at that memory.  But the whole point
of GC is to manage memory without user intervention.  So this whole
business of circumventing the GC is really just forcing a kind of
manual allocation on top of an automatic allocation system.  That's
not to say that GC doesn't have it's place, because it clearly does.
But I prefer choice, and in C++, you don't cheat the memory system
to make it do what you want.  You just make it do it the right way
the first time.  If that means using refcounting, so be it.  If it
means using cyclic refcounting, so be it.  If it means using tracing
collectors, so be it.  If it means using scoped wrappers, so be it.
Every technique is perfectly natural and "native" to the system.

Dave

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev