Re: [SERVER] JIT compilation of MOO code

• Date: Mon, 11 Nov 1996 16:37:44 PST
• From:
  Michael Brundage <brundage@laurel.ipac.caltech.edu>
• cc: moo-cows@parc.xerox.com
• Content-Type: TEXT/PLAIN; charset=US-ASCII
• In-Reply-To: <Pine.SUN.3.95.961111121603.2228A-100000@ren.us.itd.umich.edu>

On Mon, 11 Nov 1996, Christopher Unkel wrote:
> On Mon, 11 Nov 1996, Michael Brundage wrote:
> >    - differentiate between constant and mutable strings (String and 
> >      StringBuffer in Java)
> 
> I don't see how this can be accomplished in a weakly-typed language such a
> MOO; without declarations, how can we get to "constant" strings?

Perhaps I wasn't clear -- I don't mean that the MOO programmer should 
know the difference, but that the VM should, in order to more efficiently 
handle strings (and possibly other constant values).  Again, I'm not 
sufficiently proficient in the server internals to even know if this 
would be a significant improvement, but it seems that if the VM 
distinguished between constant and mutable variables could easily 
produces some savings.  I.e., distinguish between the left and right hand 
sides of somemutablestring = "someconstantstring"

> >    - differentiate between property fetches and stores so that 
> >      property values could be cached if known to not be altered during
> >      task execution. This would obviate the need for things like
> >        ou = $object_utils; for each in ([1..max_object()]) 
> >        player:tell(ou:ancestors(each)); endfor
> 
> Hmm.  Not nearly as easy as you might think.
[points out that lazy evaluations across verb calls like I suggest
above are not possible]
[...]
> Perhaps there are optimizations that could be made at the VM/DB interface
> that would make it faster, however.

Oh, I don't think it's easy at all!  The idea of an optimized VM is 
mostly a fantasy which I doubt will ever come to reality (unless, ha ha, I 
do it myself).  Also, since Pavel rewrote it to handle the 
error-catching expressions, I'm sure it's pretty close to optimal 
already.  I don't know.  It just seems like a natural thing to suggest, 
and whether it could be done or is worth being done I don't have enough 
information to evaluate.

> There are also other issues, like how does the decompiler get your
> original code back.

Depends on the kinds of optimizations being done.  If subexpressions
were eliminated, function calls inlined, and that sort of thing,
I guess it would be tricky, but surely it can be done.

> >    - provide a mechanism for just-in-time compilation into native
> >      object code.  I wouldn't expect this to be fully implemented for
> >      any given architecture, but it would allow motivated individuals
> >      an opportunity to add support for it without each such person
> >      rewriting it themselves.
> 
> Yeah, this would be cool, presuming it was done in a way such that it
> resulted in very fast and RELIABLE code.  The problem is, it is anything
> but easy.  I wouldn't hold your breath... ;>

Oh, I'm not.  The only reason I suggested it at all is because I would 
like to play around with doing that on a PowerMac, if I can ever find the 
time.  Every time I watch a large-scale simulation zip by at 500 
particles per second, I think, gee, this baby could really run a fast MOO...

michael
brundage@ipac.caltech.edu

• Re: [SERVER] LambdaMOO 1.8.x feature wishlist
• From: Christopher Unkel <cunkel@us.itd.umich.edu>

• Prev: Re: [SERVER] Customizable exceptions
• Next: [SERVER] LambdaMOO 1.8.x feature wishlist
• Index: MOO-cows
• Thread: MOO-cows