[Mono-dev] minimal mono embedding profile - hpc twist

[Rodrigo Kumpera]

On Wed, Oct 3, 2012 at 3:41 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:

>
> On Oct 3, 2012, at 2:57 PM, Rodrigo Kumpera wrote:
>
>
>
> On Wed, Oct 3, 2012 at 1:59 PM, sebastian <
> sebastian at palladiumconsulting.com> wrote:
>
>>
>>
> Finally, we may want to tweak the parameters sent to the LLVM compiler to
>> optimize for runtime speed, even at the cost of very slow compilation.
>>
>
> Tweaking llvm parameters require changing mono's source code and pretty
> much voids any guarantees that the resulting code will work.
> A lot of LLVM optimizations for some reasons produce bad code when used
> with mono. Zoltan can better explain this, I guess.
>
>
> I am very interested in this topic as well.   Squeezing the most
> performance I can for numerical work is important for my application.
>
> Sebastian, I am not sure what sorts of algorithms you are running, but
> there are a number of flags one can use, such as -O=unsafe and inlining
> directives that get mono --llvm very close to GCC compiled C / C++ code for
> numerical algorithms.   I've found that with careful structuring get within
> 5-10% of C speed.
>
> However, Mono (and the MS VM, I believe) are not all that aggressive with
> inlining.   Many of the situations that would like to inline are somewhat
> complex to detect / guard.   Mono (and I believe the MS .NET runtime) will
> not attempt to inline calls in various settings, such as if is virtual.
> There would have to be conditional code generated for the situations where
> a call would need to be virtual and where it could be known to be a
> concrete terminal type.
>

You can force more agressive inlining of methods by using
[MethodImpl(MethodImplOptions.AggressiveInlining)] or [MethodImpl(256)] (if
you're not on 4.5) on them. This will still block inlining in a few cases
but will give you quite a bit of headroom.



> A more general question to the Mono team, does the mono-llvm fork pull in
> new functionality from the LLVM project from time to time?  Should we
> expect to be able to take advantage of the new optimisations (for example
> the deeper vectorization work in progress) when they become available?    I
> recall that there were a number of deficiencies with the LLVM that required
> a lot of scaffolding in order to interoperate with the mono runtime.
> Curious whether the LLVM foks have thought to address these so that could
> make more direct use of core LLVM in the future?
>

Yes, we track updates of upstream LLVM, you can notice that in what we have
on trunk and what 2.10 uses. We're not very aggressive in tracking their
release schedule given they have a very poor backward compatibility story.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20121003/c864b55f/attachment.html>