From: Eliezer Yudkowsky (sentience@pobox.com)
Date: Sun Dec 08 1996 - 16:03:52 MST
> Since the the more advanced simulations will suck more server
> time, it would make sense that we have some way of allocating
> resources according to people's ability to effectively use them. It might
> even prove an interesting exercise in a completely
> laissez-faire system - people can gain credits for building a cool addition
> to the world and charging admission
Ah, the quota battles begin! Quota on LambdaMOO was handled, last time
I checked, by the ARB - the Architecture Review Board, I think it was.
Ironically, arbitration is handled by the mediation system, which is
totally unrelated to the ARB.
Again from personal experience, I'd say there are three important things
to remember about server-side resources:
1) When a better solution comes along, enforce it.
If LambdaMOO wasn't using their old obsolete systems it would cut
quota
usage in half and lag would go down 95%.
2) Keep only active areas in active memory.
On LambdaMOO, EVERYTHING is kept in RAM. As opposed to WorldMOO,
where
things like help systems can be kept on disk.
3) Track the usage of actual resources.
LambdaMOO used to have an object quota; you got twenty objects. This
encouraged huge monolithic programming; there was no restraint on the
number of methods on an object or how long those methods were.
Object-oriented programmers were penalized because they could only use
one object.
By the time they switched over to tracking bytes, the damage was done.
All the core systems were these ridiculously large monoliths - I believe
that an advanced old-style room cost 20K of OVERHEAD.
They still don't track CPU usage and as a result, command-line orders
can take from 8 to 60 seconds to execute, with around 20 being around
average. This is because the system is so OVERLOADED with these
gigantic monoliths.
Overall, I'd say introduce a system where:
1) A guy gets X bytes of RAM, Y bytes of disk space, and Z CPU
cycles/day.
2) The core architecture is laid out by a programmer who breathes the
programming language being designed in. Java is not C or even C++; make
sure the world-builder knows that.
> (We can worry about building a "Permutation City" a little
> closer to the Singularity...:))
One of my all-time favorite books. Vivid, realistic pictures of
uploading,
although, alas, upgrading is not addressed. Three cheers for Greg Egan!
--
sentience@pobox.com Eliezer S. Yudkowsky
http://tezcat.com/~eliezer/singularity.html
http://tezcat.com/~eliezer/algernon.html
Disclaimer: Unless otherwise specified, I'm not telling you
everything I know.
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 14:35:52 MST