16

The Mono with LLVM project is able to use the LLVM compiler back-end which has some pretty powerful optimizations to compile a C# .NET project, which get it running about 20% faster in computationally intensive applications.

Mono is now able to use LLVM as a backend for code generation in addition to Mono's built-in JIT compiler. This allows Mono to benefit from all of the compiler optimizations done in LLVM. For example the SciMark score goes from 482 to 610.

So is it possible to target an existing C# .NET project to use Mono/LLVM in order to get faster applications for Windows or Unix? Is it quite that easy or would you have to refactor/modify the application code? Will this even work under the regular .NET Framework or is this specifically for the Mono Framework project? Considering this was stated:

This extra performance comes at a cost: it consumes more time and more memory to JIT compile using LLVM.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Robin Rodricks
  • 110,798
  • 141
  • 398
  • 607
  • 2
    BTW, aside from using --llvm, there are other optimisations that are helpful, particularly for numerical applications. Suggest trying mono --llvm -O=unsafe. Additionally, one can increase inlining by setting an evironment variable, like: MONO_INLINELIMIT=128 – Jonathan Shore Sep 01 '12 at 12:30

4 Answers4

4

The LLVM backend is hooked into Mono's JIT compiler (the thing that converts the IL assembly to native assembly when you run the application), so you need to run the application with Mono.

Ivan Zlatev
  • 13,016
  • 9
  • 41
  • 50
  • Does the Mono .NET Framework differ greatly from Microsoft's implementation on Windows 7? Is it exchangeable with MS .NET 4.0? How hard would it be to port an existing .NET app to use Mono? What are the advantages/disadvantages of the Mono framework? – Robin Rodricks Jul 30 '12 at 10:37
  • That's a very hard question to answer as the answer in most cases is "it depends" - on your app, complexity, what it uses, etc. But to be honest I personally wouldn't have any expectations that Mono will work better on Windows since its main platforms are Linux, OS X and mobile. – Ivan Zlatev Jul 30 '12 at 12:42
  • Mono is quite speedy but you aren't going to win any head-to-head performance battles by relying on JIT optimizations. – IanNorton Jul 30 '12 at 20:27
  • Mono runs fine in a .NET environment. In fact it is compatible with most MS targeted DLLs etc. I have found that a Mono binary still does perform better on a Windows OS than Linux, at least for self-hosted "ASP" or "MVC" – FlavorScape May 31 '13 at 16:54
3

The first thing you need to do is run your program under a profiler, and then look at the results to find hot-spots or methods that get called too often.

For a normal run-of-the-mill desktop application you will not gain much in the way of significant performance by relying on low-level optimizations in .NET/Mono. This isn't C/C++.

Community
  • 1
  • 1
IanNorton
  • 7,145
  • 2
  • 25
  • 28
  • 1
    I'm not talking of a normal run-of-the-mill app. This question is specifically for computationally intensive applications. – Robin Rodricks Jul 31 '12 at 11:51
  • 1
    Then you need to be sure you have chosen the right tool for the job, I say this as someone who strongly supports mono and uses it nearly every day to great effect but perhaps mono or .Net isn't the right tool if you are aiming for real-time/intense processing. Alternatively, it might be cheaper ( in both time and money ) to simply get more RAM and more CPU cores. – IanNorton Aug 01 '12 at 07:19
  • 4
    @IanNorton: I don't totally agree with that. If you know what you are doing, can get very close to C++ / Fortran speed for numerical applications. This would entail using --llvm and -O=unsafe (to avoid array bounds checking). May also want to tweak the inlining limit. I've run side by side comparisons of numerical algorithms with the above and have seen negligible difference in performance (4-7%). That said, LLVM has yet to meet gcc in some specific cases of auto-vectorization. It is moving forward and hopefully the mono fork pulls in these changes over time. – Jonathan Shore Sep 01 '12 at 12:33
2

While a CPU or time based profiler will help you compare metrics against a benchmark in this case, a hotpath or method hotspots won't change when changing compilers, but through a different execution path of your test.

Hot paths, methods with high exclusive bytes are an artifact of your application code, not how that code is translated and optimized on the native CPU. Having said this tools like perfview using Event Tracing for Windows (ETW) provide JIT-specific stats and a host of sampling or time based profilers can be used for microbenchmarking, but this can be challenging to get right.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
breen
  • 51
  • 4
1

My benchmarks show that Mono often takes around 2x as much time to do the same tasks as MS .NET. So making Mono 20% faster with LLVM is not enough to make it catch up to Microsoft. Also, for some reason when I used the --llvm flag on Windows, is made virtually no difference; perhaps LLVM was even disabled on Windows for some reason (or was, back in 2011 when I did the benchmarks).

Qwertie
  • 16,354
  • 20
  • 105
  • 148
  • What version of LLVM are you talking. 3.3 just came out with a number of multi-thread vectorization optimizations for loops. – FlavorScape May 31 '13 at 16:51
  • I have no idea what version of LLVM was embedded in Mono at the time. Anyway I'd guess that Mono with LLVM is still not as fast as .NET because maybe they can't enable all possible optimizations, either because it hurts startup performance excessively or due to structural limitations of Mono. I don't think that LLVM itself is to blame; certainly LLVM can generate faster code than .NET's JIT in theory, and it does so when compiling C++. – Qwertie Jun 01 '13 at 16:09