[MUD-Dev] DBs and Events

[Jon A. Lambert]

On 11 Feb 98 at 11:24, Nathan Yospe wrote:
> On Tue, 10 Feb 1998, Greg Munt wrote:
> :On Tue, 10 Feb 1998, Nathan Yospe wrote:
> 
> :> On Tue, 10 Feb 1998, Greg Munt wrote:
> 
> :> :Also, any references to caches?
> 
> :> Again, can't help you. I've done caches, but not for my mud... and there
> :> is such a broad spectrum of things that qualify as cache. Do you want to
> :> know more about cached in-memory storage for a disk-based DB? 
> 
> :Yes.

See Cold, Cool and Uber(or is that Unter?).

> :> Or bottleneck spot caching?
> 
> :What's that?
> 
> An element of assembly coding and RISC compiler design. It might also be
> significant for VM construction. It has to do with the repeated register
> loading of the same data over and over. Essentially means finding where,
> when, and how information can be loaded onto the stack/into registers to
> minimize the number of loads (This opposed to operational instructions.)
>

Nod. Being terminology challenged in the areas of compiler theory and
hardware, I lump this in the category of "code optimization" in my VM.  
It certainly has significance in my VM.  

While Nathan's point is specific it does touch on a good general principle, 
even if you are not writing assembly or VMs.  Pay some attention to your
architecture.

For instance, in an RGMA flame-fest not long ago, one poster bemoaned the 
fact that the old MS-C compiler by default did register alignment on data 
as opposed to the *nix GCC compiler.  I was curious about this and found 
some rather enlightening things about 8086 architecture.  By turning this 
option on, I got around a 25% boost in speed.  Of course nothing comes 
for free and there are few downsides to this.  Executables are quite a bit 
larger and it makes all that clever (or not so clever) C pointer arithmetic 
unpredictable.  I would recommend these options if you are targetting this 
architecture and the downsides are irrelevant to you.  

> :> :Any references to Event Management? Is there any alternative to using a 
[snip]
> :I'm not sure I understand this too well. Are you suggesting this?
> 
> :class Event
> :  {
> :     private:
> :       DataType1 *a;
> :       DataType2 *b;
> :       ...
> :
> :     public:
> :       ...
> :       process();
> :  };
>

I guess I'll unzip and show you mine. 

class Event {
  Objid	    owner;   // controlling object
  Object    *callee; // object containing method
  Object	*actor;  // calling object 
  Message   *args;	 // arguments to call
  short     priority // Event priority	
  Method    *m;		 // method to execute
  TTime     birth_time  // timestamp on queue
  TTime     exec_time // scheduled execution time
};

class Task {
  Event    *event    // executing event	
  long		msgid;	 // unique task ID	
  long		wait;    // wait time		
  long		ticks;	 // execution time	
  int		retry    // interval in msecs to retry event 
  int		sp;		 // stack pointer 
  int		pc;		 // program counter 
  Var	    *stack   // stack 
  int       st_size  // current stack size
  short     priority // thread priority
  PThread   exec_hndl // Handle to execution thread
  void     *localTD  // Handle to protected thread data
public:
 (... lots of functions ...)
};

I now feel some embarassed at exposing myself; yet strangely unburdened. ;)
 
> class Event{
>   SortedList<ObjectReference<BaseObject>, PrioriList<AttributeType,
>       AttributeValue> > objectList;
>   TimeValue  timeCheck; // for purpose of sanity checks
> public:
>   process(); // set values... for each object in objectList, call
>              // BaseObject::update();
> };
> 
> :I still can't see how the event isn't a function. The tasks that the 
> :event does have to be stored in a function?
>

Well try to think of all items within an object as just data.  Assign no
importance as to whether something is a function or not.  It is merely a 
pointer to more data.  Pay no attention to the little man behind the 
curtain.  It's not easy for me either, since I mentally tend to 
differentiate functions from procedures.

> Well, yes and no. I operate entirely on the principal of creation, value
> modification, full instantiation, partial destantiation, and deletion. I
> don't tolerate the sort of procedural functions that most languages use.

Grin.  Nathan has been fully abstracted.  
 
[snip]
> 
> :I'll use this opportunity to keep you updated on my work activities: I 
> :finally got a job, C++/Unix, using such tools as Rational Rose, etc. I'll 
> :be maintaining and developing planning and scheduling software for the 
> :steel industry. Will post a FAQ update soon.
> 
> Congratulations. Rational Rose, eh? I have misery in my company. I mean,
> company in my misery. No the first time was right. We use Rose too. Dang
> piece of ill concieved code. Powerful, though. But... how can a tool for
> object oriented design be so... inconsistant? It seems to have spaghetti
> for innards, and the user interface changes from one tool to the next so
> radically that the keys for _copy_ and _paste_ are never the same, and I
> don't even want to go into the deletion and selection procedures. Bleah!
> 

Hmm.  Another Rational Rose user.  I like it, but have been burned.  
Hint: Keep good backups of all iterations of clean source as well as
the .mdl's that generated them.

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--