1998Q4/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD&#45;Dev] Re: PDMud thread summary -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Sun, 25 Oct 1998 22:18:18 &#45;0800 -->
<!--X-Message-Id: 199810260615.AAA10968@dfw&#45;ix7.ix.netcom.com -->
<!--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] Re: PDMud thread summary</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:jlsysinc#ix,netcom.com">
</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>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->

Date:&nbsp;
[&nbsp;<a href="msg00510.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00512.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00512.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00537.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00511">Author</A>
&nbsp;|&nbsp;<A HREF="#00511">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00511">Thread</A>
&nbsp;]

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: PDMud thread summary</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] Re: PDMud thread summary</LI>
<LI><em>From</em>: "Jon A. Lambert" &lt;<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>&gt;</LI>
<LI><em>Date</em>: Mon, 26 Oct 1998 01:15:32 -5</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#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>
On 23 Oct 98, Cynbe ru Taren wrote:
&gt;
&gt; Excuse, I haven't been following recent traffic, had my nose
&gt; buried in paidwork and trying to get my mu* beta out the door. :)
&gt;

Long time, no post. :)
 
&gt; 
&gt; | I think Chris Gray mentioned fixing bytecode memory addresses 
&gt; | at startup, allowing direct jumps into functions.  While a performance
&gt; | boost, it makes dynamic registration and unregistration of modules
&gt; | more complex.  
&gt; 
&gt; I'd suggest computing just how much of a win the address swizzling
&gt; is.  I'll predict the win is less than a three percent speedup in
&gt; typical code [*], in which case one has to wonder whether it is worth
&gt; the extra design, coding, debugging and maintainance effort for
&gt; a speedup few if any users are ever likely to notice...

As long as the design is flexible, an optimization of this nature can 
be postponed, until if and when needed.   

&gt; [*] Based on experience with my Muq design, in which I run -all-
&gt; pointer references through a hashtable with only about a 5% speed
&gt; penalty.  Lets me shuffle objects freely both in memory and between
&gt; memory and disk, which to me is a win worth the price.

Nod.  My experiences with DB cacheing would lead me to believe
that performance is quite reasonable.
 
&gt; | Having the return value, buys nothing either, since the caller may not use 
&gt; | it and wouldn't be able to build a proper mangled name.  
&gt;   
&gt; Function calls and function returns logically have a strong
&gt; symmetry:  It is rather artificial to support multiple args
&gt; but not multiple return values.  Current programming habits
&gt; don't make heavy use of multiple return values, but this may
&gt; change, and to me seems to be slowly changing.  E.g., Perl
&gt; programmers make relatively heavy use of multiple return
&gt; values.

Interesting.  I admit I had not thought along these lines, but it's 
certainly an artificial restriction.  I had envisioned a language 
that was easily understood by novice programmers.  I wonder how 
easily how this concept would go over.

Something like this?

x, y, z = foo( a, b, c);

&gt; | int cast(int time, string spell)  ----&gt;   #magic@cast$ai$as 
&gt; | char foo(char * bptr, bar i)    ----&gt;  #magic@foo$apc$aebar
&gt; 
&gt; Depending on the context, you might want to use a hash of the
&gt; mangles instead of using the mangles themselves.
&gt; 

A very good idea.  Thanks.
 
&gt; | For a standard call format, why not just have the caller push() it's address and then all the 
&gt; | arguments from left-to-right onto the stack then jump to the callee.  The callee pops() them 
&gt; | out and loads local variables right-to-left.  Return would pop() the return address off the 
&gt; | stack and push() the result and jump to the address just popped.
&gt; 
&gt; Sounds like the call sequence is doing an extra stack-to-stack copy.
&gt; Is there a good reason to spend time on this?  Why can't the local
&gt; variables be located where the caller leaves the args?

It depends.  Any comments on how arguments should be passed to 
module functions?  By copy, by unmodifiable reference or modifiable 
reference? 

&gt; | This is pretty simple.  There maybe better ways of doing this.  Message passing perhaps?
&gt; | Thoughts?
&gt; 
&gt; Remember to push the argument count.  Sooner or later you'll want
&gt; to have variable numbers of arguments, and architecting the possibility
&gt; out of existence will suddenly look stupid.  Call/return symmetry suggests
&gt; pushing the number of return values when returning, as well.

Good point.  Although this need only be done for variable argument 
functions.  Functions which match mangled name prototypes will 
inherently know how to pop arguments.  
   
&gt; Don't get obsessed by speed to the point of screwing up clean semantics
&gt; to buy a fraction of a percent speedup:  If speed matters that much,
&gt; you shouldn't be using a bytecoded implementation anyhow.

Yes.  A slow implementation which is functionally cohesive and 
loosely coupled can be tweaked and optimized in many ways, later.  
A design which is built predicated upon optimization concerns will 
quickly become very inflexible and limiting, making some later 
optimizations impossible.

&gt; As a final thought, I've gone to doing everything 64-bit at this
&gt; point.  32-bit architectures are clearly a sunset industry at this
&gt; point, and starting new servers 64-bit avoids issues of converting
&gt; 32-bit dbs to 64-bit architectures during the transition.  I clocked
&gt; less than a 15% slowdown for doing this on Intel, which to me for
&gt; my application is worth the price:  Your milage may of course vary,
&gt; but again, if a 15% speedup matters, should you be using bytecodes
&gt; at all?

Not to mention double-byte unicode concerns.  I agree that 64-bit 
architectures will become de facto standard very very soon.  

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


</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00510.html">[MUD-Dev] Missing the point:  OpenMUD, Gamora, Casbah, etc.</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00512.html">[MUD-Dev] Re: PDMud thread summary</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00512.html">[MUD-Dev] Re: PDMud thread summary</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00537.html">[MUD-Dev] Re: PDMud thread summary</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00511"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00511"><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>[MUD-Dev] Re: PDMud thread summary</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00503" HREF="msg00503.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, 
ApplePiMan <a href="mailto:ApplePiMan#aol,com">ApplePiMan#aol,com</a>, Mon 26 Oct 1998, 00:20 GMT
</LI>
<LI><strong><A NAME="00507" HREF="msg00507.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, 
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Mon 26 Oct 1998, 04:20 GMT
</LI>
<LI><strong><A NAME="00508" HREF="msg00508.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, 
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Mon 26 Oct 1998, 04:35 GMT
<UL>
<LI><strong><A NAME="00512" HREF="msg00512.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, 
Alex Oren <a href="mailto:alexo#bigfoot,com">alexo#bigfoot,com</a>, Mon 26 Oct 1998, 09:41 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00511" HREF="msg00511.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, 
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 26 Oct 1998, 06:18 GMT
</LI>
<LI><strong><A NAME="00537" HREF="msg00537.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, 
Bruce Mitchener, Jr. <a href="mailto:bruce#puremagic,com">bruce#puremagic,com</a>, Tue 27 Oct 1998, 04:45 GMT
<UL>
<LI><strong><A NAME="00656" HREF="msg00656.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, 
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Sun 01 Nov 1998, 04:02 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00539" HREF="msg00539.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, 
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Tue 27 Oct 1998, 06:05 GMT
</LI>
<LI><strong><A NAME="00540" HREF="msg00540.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, 
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Tue 27 Oct 1998, 06:13 GMT
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>

</ul>
<hr>
<center>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
</center>
<hr>
</body>
</html>