MOO-cows Mailing List Archive
Re: [SERVER] JIT compilation of MOO code
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...
Subject Index |