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

[Jonathan Shore]

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:

the DynamicMethod continues to be JIT'ed by the mono JIT engine (instead of LLVM)
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:
> 
> I assume I can remove a class created with the compiler as a service?
> 
> No, class unloading only happens as part of AppDomain unloading.
> Would there be residual in the JIT or elsewhere that will accumulate, becoming a memory leak issue?
> See the above. 
> 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.
>  
> 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/3df6ead4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.cs
Type: application/octet-stream
Size: 2066 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120214/3df6ead4/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120214/3df6ead4/attachment-0001.html>