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

[Jonathan Shore]

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.  

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20121003/eca327ed/attachment-0001.html>