[DGD] Current Status of VM efforts

[Shentino]

You'd probably be best binding any JIT state to the control block.

Also remember that, per the documentation for compile_object kfun, object
bytecode upgrades don't take effect until the end of the task that triggered
them, with all the due caveats that atomic functions imply.

Just remember that bytecode can be volatile, so make sure that any JIT that
follows it keeps track accordingly.

On Sun, Aug 7, 2011 at 3:53 AM, Carter Cheng <cartercheng at gmail.com> wrote:

> Appreciate the help Shentino.
>
> On Sun, Aug 7, 2011 at 8:37 PM, Shentino <shentino at gmail.com> wrote:
> > On Sun, Aug 7, 2011 at 3:29 AM, Carter Cheng <cartercheng at gmail.com>
> wrote:
> >
> >> Shentino thanks. Since you are around I do have a followup question
> >> for you (since you have been stress testing the dgd server). I have
> >> been thinking of compiling a version of this server with profiling on.
> >> Is there some methodology you have for assessing the performance?
> >> Dworkin do you have any idea here?
> >
> >
> > My guess is that you'd definitely want to pay attention to i_interpret
> > and/or i_call
> >
> > JIT can only help with bypassing interpretation of machine code, and you
> > still have invariant overhead elsewhere (processing callouts, handling
> > network I/O, swapping, etc) that JIT won't influence.
> >
> > To be quite frank, as far as my tests go, mostly I've been pushing the
> > envelope so hard that I wind up exposing bugs long before I get around to
> > performance evaluations.  Most of my attempts to optimize dgd and/or a
> > mudlib running on it wind up turning into segfaults...and then into
> patches
> > from dworkin.
> > ___________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>