There seems to be some discussion about Mono's performance, and I wanted to address that.
The default configuration for Mono is a blend of fast startup, and decent code speed. You can tune these parameters depending on your use profile which can range all the way from: startup is the most important factor to high performing code at any cost.
In general the language Shootout compares the default configuration of Mono vs all kinds of other configurations.
Those interested in Mono for High Performance Computing will be interested in some options:
* LLVM: passing the --llvm flag to Mono instructs Mono to pass the code to the LLVM optimizing compiler, and will run your program through every heavy weight optimization that LLVM supports. This comes at the price of slow startup times (much slower), but for HPC or server loads, the extra time it takes to JIT is worth it.
* Unsafe mode. If you have battle tested your application and you never get an IndexOutOfRange exception, you can instruct Mono to never perform array-bounds checking. Arrays bounds checking basically ensures that every time you do array [i] that the value of "i" is within the range 0..array.Length. This can be expensive, but makes your program safe.
Passing -O=unsafe basically gives you the same semantics of C or C++: you know what you are doing, and you really are not too much into safety.
With LLVM + unsafe access, as far as the LLVM optimizer is concerned, there is really no difference between C# and C++ code, and you will get the same performance for compute intensive tasks. The only case where the dynamic of performance would come into play is when the garbage collector kicks-in, vs manual memory management. That in general depends a lot on the kind of app you are building. Many HPC applications preallocate all of their memory before large computations anyways, so in those apps the GC makes no difference.
The third optimization is to use Mono's new garbage collector, which gives in general a nice 2x performance boost to memory intensive applications. In general, the new GC is great for memory intensive applications, while the old one is better for pure computational applications that are not memory allocation bound.
With Mono 3.0, we also have implemented the inlining attribute (new in NET 4.5), which developers can use to force a function to be inlined, something that before was entirely based on JIT heuristics.
And of course, you can tune the individual Mono or LLVM optimization options.
The default configuration for Mono is a blend of fast startup, and decent code speed. You can tune these parameters depending on your use profile which can range all the way from: startup is the most important factor to high performing code at any cost.
In general the language Shootout compares the default configuration of Mono vs all kinds of other configurations.
Those interested in Mono for High Performance Computing will be interested in some options:
* LLVM: passing the --llvm flag to Mono instructs Mono to pass the code to the LLVM optimizing compiler, and will run your program through every heavy weight optimization that LLVM supports. This comes at the price of slow startup times (much slower), but for HPC or server loads, the extra time it takes to JIT is worth it.
* Unsafe mode. If you have battle tested your application and you never get an IndexOutOfRange exception, you can instruct Mono to never perform array-bounds checking. Arrays bounds checking basically ensures that every time you do array [i] that the value of "i" is within the range 0..array.Length. This can be expensive, but makes your program safe.
Passing -O=unsafe basically gives you the same semantics of C or C++: you know what you are doing, and you really are not too much into safety.
With LLVM + unsafe access, as far as the LLVM optimizer is concerned, there is really no difference between C# and C++ code, and you will get the same performance for compute intensive tasks. The only case where the dynamic of performance would come into play is when the garbage collector kicks-in, vs manual memory management. That in general depends a lot on the kind of app you are building. Many HPC applications preallocate all of their memory before large computations anyways, so in those apps the GC makes no difference.
The third optimization is to use Mono's new garbage collector, which gives in general a nice 2x performance boost to memory intensive applications. In general, the new GC is great for memory intensive applications, while the old one is better for pure computational applications that are not memory allocation bound.
With Mono 3.0, we also have implemented the inlining attribute (new in NET 4.5), which developers can use to force a function to be inlined, something that before was entirely based on JIT heuristics.
And of course, you can tune the individual Mono or LLVM optimization options.