<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] ColdStore. Belated response from a developer. -->
<!--X-From-R13: pbyvaNsvryq.zrqvpvar.nqrynvqr.rqh.nh -->
<!--X-Date: Fri, 21 Apr 2000 21:13:07 -0700 -->
<!--X-Message-Id: 20000422001959.76C5B2F02C@sharedtech.eyep.net -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] ColdStore. Belated response from a developer.</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:colin@field.medicine.adelaide.edu.au">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00500.html">Previous</a>
| <a href="msg00503.html">Next</a>
]
Thread:
[ <a href="msg00523.html">Previous</a>
| <a href="msg00531.html">Next</a>
]
Index:
[ <A HREF="author.html#00502">Author</A>
| <A HREF="#00502">Date</A>
| <A HREF="thread.html#00502">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] ColdStore. Belated response from a developer.</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] ColdStore. Belated response from a developer.</LI>
<LI><em>From</em>: <A HREF="mailto:colin#field,medicine.adelaide.edu.au">colin#field,medicine.adelaide.edu.au</A></LI>
<LI><em>Date</em>: Sat, 22 Apr 2000 10:19:59 +1000</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
I write this in response to a thread from December 1999, of which I've just
become aware. In the thread, Miro <silovic#zesoi,fer.hr> attempts some
helpful criticism of ColdStore, which I seek to rebut here.
Miro writes, of ColdStore,
> It's a C++ library that mmaps a file, and then handles the allocation and refcounting. This is very fast, of course, as the allocation handles the locality, but that's the only good thing one can say this approach. Problems:
>- mmap is limited by the architecture. With normal databases you can download
as needed, and the db file(s) can be bigger than the address space - if you
carefully split your db, for example. With mmap, you're limited to the largest
contiguous segment in your address space, which really is about 1 gb on most
OSes.
That's true. 64bit machines are around the corner: when the machine's address
space exceeds your available disk storage this limitation disappears.
>This seems a lot but I know of at least one production MUD whose db size hit
1gb at one point (that's when they rewrote much of their code for data size
efficiency) - and that was Cold db that compresses small integers, so it'd be
1.5-2gb of pure mmapped binary.
ColdStore compresses small integers too.
I'd have thought the storage between Cold and ColdStore was comparable.
>- bug recovery is nonexistent. If your broken C++ code hits mmaped memory,
you can say goodbye to the entire db.
ColdStore doesn't set out to make C++ programming safe, because that's
impossible. It sets out to provide a toolkit for supporting higher-level
interpreted languages in which one would write applications.
It's certainly necessary to thoroughly engineer the C++ classes you use and to
avoid world-stopping bugs, however Miro's argument could apply to any complex
piece of code upon which your world depends, the o/s, the db backend.
You could look at ColdStore as a C++-extensible database engine which has been
optimised for the kinds of storage one would require for MUDs. Certainly, if
the database is buggy your MUD will be toast. Recommend: don't extend the db
with buggy code.
>- versioning issues. While upgrading ColdStore may be handled, If you change
layout of your objects, well... conversion is impossible, since you've just
mmaped the binary.
ColdStore defines a virtual protocol based roughly on Python's API. One of
the extensions is a toconstructor() call, which is intended to be used to
serialise objects for the purpose of reconstruction.
>Note that mmapped is okay if you make it possible to serialize the object in
some intelligent way and then copy them into the mmapped memory.
One could certainly use the toconstructor() facility for changing the raw
layout of objects.
This would be painful, however, and one would be well advised to think through
the raw layout of lowest level objects before committing them to persistent
store.
>- db format is highly non-portable. It's not just architecture dependant,
it's C++ compiler dependant (as object layout may change).
Certainly. It was a design decision to localise the cost of moving between
architectures to the time when one might wish to actually move them, rather
than seek to support an abstracted/portable format for which one pays on each
access.
Many database formats are not immediately/binary portable, usually the
databases have to be serialised or marshalled before moving them.
>- refcounting. Well. Some people swear by it. Usually the same people who
haven't explored its interactions with threading.
I was in the process of writing it right out in favour of GC, when someone
pointed out to me that refcounting is a great storage optimiser - ColdStore
collections and vector types share all substructure, and implement Copy On
Write semantics on low level objects.
> The issue is that increasing refcount needs to be done atomically - when you have LOTS of threads, well... that just won't work.
Of course it will work. It just entails some possible contention. Most
modern (like, post Z80 :) CPUs provide for atomic increment/decrement of
integers because, as Miro says, there's a lot of contention for counters.
>You either have to use extra spin lock or use inline assembly for atomic
increment. And since you increment/decrement refcounts a LOT (even passing
pointers as parameters may cause refcounts to bump), this is major issue.
I don't see the problem with using inline assembly for atomic increments,
that's what inline assembly is for. It's what we use, nicely wrapped in a
Counter class.
Maximising data locality by sharing substructure will always tend to increase
contention between threads at the same time as it tends to decrease page
faults. This is a classic trade-off: throughput vs. responsiveness. Are
networks really fast enough, yet, that response-lag is an issue?
As long as the time taken to swap a page from disk is much longer than a
thread context switch, I'll tend to worry more about locality than thread
performance, most particularly since most of large MUD architectures don't
even have real multitasking.
>BTW, has there been any discussion on the list on incremental/generational
GC? (that works best for MUDs by far, IMHO - you can really bump up your
realtime response once you implement incrementality properly).
As mentioned, while concurrent GC is a really interesting field, refcounting
is not merely a garbage collection facility.
>- no way to logically split your db into multiple files. ColdStore stores
direct binary pointers.
Later versions may provide for a tiling of mmaps over the address space.
> You also have Texas Persistent Store [...] ColdStore authors chose not to implement this because, according to them, it performs really slowly.
Yes, according to reported benchmarks it performs 10,000 times slower than the
equivalent direct pointer access methods.
Additionally, the authors of Texas don't answer email, the build process
entails heavy use of a hacked gdb (using STABS to generate object
interpretation code for swizzling) and Texas has no support for dynamically
loading new objects into a store.
>I'd say [ColdStore] is great for small MUDs that need to run on tiny (read:
outdated) servers and aren't changed a lot after the initial hardcode is in
place.
I'd never seek to write any MUD but a trivial MUD directly on ColdStore layer1
object protocol, but then that's not what ColdStore was designed for.
I think layer1 is a fairly good base for implementing virtual machines, at
what we've called layer2, and would welcome criticism of ColdStore with this
intended use in mind.
We're currently developing languages and their associated virtual machines at
layer2, I think it would make sense to use the languages being built on layer2
to implement a MUD-like system.
>It's faster than anything that uses separate db engine and it handles small
dbs efficiently. But I think it'd be a mistake to use it for a (potentially)
large size world.
I don't consider 1.75Gb to be small, on a 32bit machine. And given our
current rate of progress, 64bit systems will be prevalent by the time we
deliver our first Dispute Resolution System object :)
Colin.
_______________________________________________
MUD-Dev mailing list
MUD-Dev#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00531" HREF="msg00531.html">Re: [MUD-Dev] ColdStore. Belated response from a developer.</A></strong>
<ul compact><li><em>From:</em> Miroslav Silovic <silovic@zesoi.fer.hr></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00500.html">[MUD-Dev] shrink wrapped mud development kit (fwd)</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00503.html">Re: [MUD-Dev] Character persistance, was Family, was characters per account</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00523.html">[MUD-Dev] Game Spec</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00531.html">Re: [MUD-Dev] ColdStore. Belated response from a developer.</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00502"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00502"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] LED0</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00534" HREF="msg00534.html">Re: [MUD-Dev] LED0</A></strong>,
Frank Crowell <a href="mailto:maddog@maddog.com">maddog@maddog.com</a>, Sun 23 Apr 2000, 21:46 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00521" HREF="msg00521.html">[MUD-Dev] [Meta] Ex-Origin Employees to new Verant studio</A></strong>,
Eli Stevens <a href="mailto:wickedgrey@wickedgrey.com">wickedgrey@wickedgrey.com</a>, Sat 22 Apr 2000, 18:12 GMT
<LI><strong><A NAME="00524" HREF="msg00524.html">Re: [MUD-Dev] BioWare to demonstrate Neverwinter Nights at E3</A></strong>,
Jeff Freeman <a href="mailto:SkeptAck@antisocial.com">SkeptAck@antisocial.com</a>, Sat 22 Apr 2000, 18:11 GMT
<LI><strong><A NAME="00523" HREF="msg00523.html">[MUD-Dev] Game Spec</A></strong>,
Jman77777 <a href="mailto:Jman77777@aol.com">Jman77777@aol.com</a>, Sat 22 Apr 2000, 18:11 GMT
<LI><strong><A NAME="00502" HREF="msg00502.html">[MUD-Dev] ColdStore. Belated response from a developer.</A></strong>,
colin <a href="mailto:colin@field.medicine.adelaide.edu.au">colin@field.medicine.adelaide.edu.au</a>, Sat 22 Apr 2000, 04:13 GMT
<UL>
<LI><strong><A NAME="00531" HREF="msg00531.html">Re: [MUD-Dev] ColdStore. Belated response from a developer.</A></strong>,
Miroslav Silovic <a href="mailto:silovic@zesoi.fer.hr">silovic@zesoi.fer.hr</a>, Sun 23 Apr 2000, 21:46 GMT
<UL>
<LI><strong><A NAME="00539" HREF="msg00539.html">Re: [MUD-Dev] ColdStore. Belated response from a developer.</A></strong>,
Jay Carlson <a href="mailto:nop@mitre.org">nop@mitre.org</a>, Mon 24 Apr 2000, 01:20 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00500" HREF="msg00500.html">[MUD-Dev] shrink wrapped mud development kit (fwd)</A></strong>,
J C Lawrence <a href="mailto:claw@cp.net">claw@cp.net</a>, Fri 21 Apr 2000, 01:52 GMT
<UL>
<LI><strong><A NAME="00508" HREF="msg00508.html">Re: [MUD-Dev] shrink wrapped mud development kit (fwd)</A></strong>,
Richard Ross <a href="mailto:rross@redhotant.com">rross@redhotant.com</a>, Sat 22 Apr 2000, 04:13 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>