[Mono-dev] high-freq use of compiler as a service or reflection.emit

[Rodrigo Kumpera]

Dynamic methods are not supported with LLVM.


On Tue, Feb 14, 2012 at 7:11 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:

> In this regard I had started to experiment with DynamicMethod.  I created
> a test to explore the performance profile of dynamic compilation.   The
> test has a variety of modes, but in this case creates / compiles once and
> evaluates the delegate 1e9 times and compares to a non-dynamic delegate
> evaluated the same # of times.
>
> When running in the normal mono JIT, the emitted and explicit have
> essentially the same runtime.  With LLVM enabled, the explicit was much
> faster than the dynamically compiled.  If fact, the runtime of the
> dynamically compiled looked very similar to the default JIT performance.
> Hence am wondering whether one of the 2 things is happening:
>
>
>    1. the DynamicMethod continues to be JIT'ed by the mono JIT engine
>    (instead of LLVM)
>    2. the DynamicMethod is JIT'ed by LLVM, but the non-dynamic delegate
>    is inlined such that has no delegate overhead.
>
>
> Find the simple test code enclosed.  Thoughts?
>
>
>
> On Feb 14, 2012, at 3:42 PM, Rodrigo Kumpera wrote:
>
>
>
> On Tue, Feb 14, 2012 at 2:27 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:
>
>> I have an application where rules are generated (as part of a genetic
>> algorithm).   Rather than evaluate the rules in interpreted form (which are
>> 5x or more slower than the equivalent compiled code), thinking to use
>> reflection.emit or the mono compiler as a service.
>>
>> Millions of rules are generated across time within the scope of one
>> process / AppDomain.   During the computation of fitness each rule is
>> evaluated millions of times, but once fitness is computed, the rule will
>> never need to be evaluated again.   Computing fitness takes 10-20 seconds,
>> so the cost of this in ratio to compilation is small.   Hence increasing
>> the performance by 5x is desirable.
>>
>> With the above in mind:
>>
>>
>>    1. I assume I can remove a class created with the compiler as a
>>    service?
>>
>>
> No, class unloading only happens as part of AppDomain unloading.
>
>>
>>    1. Would there be residual in the JIT or elsewhere that will
>>    accumulate, becoming a memory leak issue?
>>
>> See the above.
>
>>
>>    1. If I am running with llvm enabled, will the compiler as a service
>>    or reflection.emit make use of LLVM for JIT?
>>
>> Yes, but expect compilation times to increase 10 fold.
>
>
>>
>>    1. Should I prefer the Mono api or reflection.emit for performance or
>>    other reasons?
>>
>>
> If you're loading assemblies, it doesn't matter.
>
> From your description you should use dynamic methods since 4.0 collectible
> assemblies are not supported.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120214/6e8c992c/attachment-0001.html>