Dynamic methods are not supported with LLVM.<div><br><div><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 7:11 PM, Jonathan Shore <span dir="ltr"><<a href="mailto:jonathan.shore@gmail.com">jonathan.shore@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div><ol><li>the DynamicMethod continues to be JIT'ed by the mono JIT engine (instead of LLVM)</li><li>the DynamicMethod is JIT'ed by LLVM, but the non-dynamic delegate is inlined such that has no delegate overhead.</li>
</ol></div><div><br></div><div>Find the simple test code enclosed.  Thoughts?</div><div><br></div><div></div></div><br><div style="word-wrap:break-word"><div></div><br><div><div>On Feb 14, 2012, at 3:42 PM, Rodrigo Kumpera wrote:</div>
<br><blockquote type="cite"><br><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 2:27 PM, Jonathan Shore <span dir="ltr"><<a href="mailto:jonathan.shore@gmail.com" target="_blank">jonathan.shore@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">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.<div>

<br></div><div>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.</div>

<div><br></div><div>With the above in mind:</div><div><br></div><div><ol><li>I assume I can remove a class created with the compiler as a service?</li></ol></div></div></blockquote><div><br></div><div>No, class unloading only happens as part of AppDomain unloading.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><ol><li>Would there be residual in the JIT or elsewhere that will accumulate, becoming a memory leak issue?</li>

</ol></div></div></blockquote><div>See the above. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><ol><li>If I am running with llvm enabled, will the compiler as a service or reflection.emit make use of LLVM for JIT?</li>

</ol></div></div></blockquote><div>Yes, but expect compilation times to increase 10 fold.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">

<div><ol><li>Should I prefer the Mono api or reflection.emit for performance or other reasons?</li></ol></div></div></blockquote><div><br></div><div>If you're loading assemblies, it doesn't matter.</div><div><br>
</div>
<div>From your description you should use dynamic methods since 4.0 collectible assemblies are not supported.</div></div>
</blockquote></div><br></div><br></blockquote></div><br></div></div>