[Mono-devel-list] Mono Interpreter: Dietmar's idea.

[Bernie Solomon]

Having done some experiments with the current interpreter I thought I'd add
a few comments on what I found. I have to admit having only been studying
the interpreter I don't know what the "IR2" list actually contains so
whether what I found is relevant I don't know.

While it is true the current interpreter tracks types on the stack I don't
think this is the major reason for slowness from what I saw (not to say if
instructions were processed such that type checks were unnecessary it would
not be faster). The reasons I noticed are:

- Continual looking up of tokens to get methods/fields/string constants and
so on. If the instructions are preprocessed in some way so that instructions
like LDFLD have the offset directly to hand, you have preloaded string
constants and know where they are so on then a lot of time can be saved per
call. I think this is the area that would give the biggest speed boost
(another
possible preprocess is to fix up endianess & alignment issues in reading
instructions).

- Copying arguments. I am not quite sure why arguments need to be copied
from the callers stack to another block of memory for the callee. At least
for a normal call from interpreted method to interpreted method. The callee
should be able to just use the stackvals in the callers stack directly since
when the call is done the values are immediately popped off the stack
so they can be safely overwritten by STARG. There may be a case where
copying is necessary if the method signature has pinvoke set but that
seems to be rare as if PINVOKE_IMPL or INTERNAL_CALL is
set those cases are taken out (calling delegates from native code
is one case - not sure about others).

- Valuetypes keep hold of their class with the value. As far as I can make
out this is not necessary as it the actual field is only used in two places:
INITOBJ - which has the class as a token which is currently ignored but
could be used instead - and in LDFLD where we can use the class from the
field (I think). So I think stackval can have this removed and be reduced in
size.

Given the current interpretation technique I think all these can be improved
though no doubt there are other areas - and maybe this is all irrelevant
if a completely different style of interpreter is used.

Bernie Solomon

----- Original Message ----- 
From: "Miguel de Icaza" <miguel at ximian.com>
To: <mono-devel-list at ximian.com>
Sent: Monday, July 14, 2003 10:08 AM
Subject: [Mono-devel-list] Mono Interpreter: Dietmar's idea.


> Hey guys,
>
>    I just saw some commits from Zoltan to the interpreter to speed it
> up, and that reminded me of a proof-of-concept work that Dietmar did
> with the old JIT engine that might be useful again.
>
>    Our interpreter is not very fast, because it has to track type
> information on the stack, for certain opcodes, like this:
>
> ldc.i4.1
> ldc.i4.2
> add
>
>     That will be an integer add, while:
>
> ldc.r4 1.0
> ldc.r3 2.0
> add
>
>     Would be a 4-byte floating point addition.
>
>     What Dietmar did before, is that he made the interpreter work not on
> the original CIL byte sequence, but on the forest-of-trees that we
> generated later.
>
>     With the new JIT, we have a structure like this:
>
> CIL -> IR1 (forest of trees) -> IR2 (list of instructions) -> native code
>
>     So it occurs to me that we could plug an interpreter for the IR2
> set of operations, this would have many benefits: it would reuse many
> of the optimizations we perform on IR1 and IR2, and it would reuse more
> of the JIT code.
>
> Miguel
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>