[Mono-dev] Ping on nternal call builders

Kornél Pál kornelpal at gmail.com
Wed Jul 30 12:04:31 EDT 2008


Hi,

>Zoltan Varga wrote:
>   This patch replaces a small, fast, simple piece of code
> in mono_emit_inst_for_method () with something far more complex. Also,

The three icall builders are reference implementations for demonstrating
what icall builders can do. I don't insist on OffsetToStringData being
replaced with an icall builder. Note that however that my tests showed
no difference in executing the code. (I didn't do tests on JIT time.)

> about replacing
> icalls with generated IL code:
> - the code to generate the icalls is usually much bigger and more
> complex than the icall
>   itself.

That's true but UnsafeAddrOfPinnedArrayElement (that is so simple code
that it should do exactly the same in C and IL) for example was running
5.7x faster and I believe only because of omitting the managed to native
transition.

> - it replaces code generated by the gcc optimizing C compiler with
> code generated by out JIT,
>   which is of much lower quality. So even tough we incur a
> managed-to-native transition
> overhead by calling native code, we get some (or all) of it back by
> having gcc compiled code
>   in the icall.

I don't believe that methods like UnsafeAddrOfPinnedArrayElement (and
there are more methods similarly using fields not exposed to corlib that
could benefit from this as well) could be optimized better by gcc than
the JIT.

I belive that memcpy for example should be implemented using native
assembly but it still is implemented in C#.

> - as rodrigo said, every new type of wrapper function adds some
> complexity to our AOT
> compiler which has to know about them.

I have little knowledge about AOT so I don't know how this affects AOT
performance.

> So I'm not against adding the _ability_ to implement icalls in IL, but
> I'm against using it in
> situations where it just makes things more complex.

I assume you mean OffsetToStringData. When I wanted to implement
UnsafeAddrOfPinnedArrayElement in mono_emit_inst_for_method it was not
accepted. Moving OffsetToStringData out of mono_emit_inst_for_method
seems not to be accepted either.

I see OffsetToStringData and UnsafeAddrOfPinnedArrayElement being
similar in that they do nothing complex just care about internal
structure details of the runtime.

The managed-to-native transition is such a big overhead (at least for
simple icalls) that its worth to implement icalls in IL that don't call
other native functions.

icall builders are my proposed solution but I'm open to any other
solution as well.

Kornél




More information about the Mono-devel-list mailing list