<!-- 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>