Miguel de Icaza Explains How To "Get" Mono

LeninZhiv writes "It's perhaps the most controversial project in the open source world, but this mostly stems from misunderstanding: Mono, the open source development platform based upon Microsoft's .NET framework. Immediate reactions from many dubious Linux developers have ranged from confusion over its connection with .NET to wondering what the benefits of developing under it are. Throughout the course of its four years of intense development, sponsored by Novell, Mono founder Miguel de Icaza has had to frequently clarify the .NET issue and sell the community on it. In this new interview, Howard Wen asks Miguel to explain himself one more time."

Comments

Re:Anyone Have Actual Experience With Mono?

[Anonymous Coward]

This is a bit long-winded, bare with me, I'm practically a ./ virgin ;)

Some time ago, getting spontaneously fed up with C++ with managing memory, obscure STL bugs and so forth, I decided to check out if Mono 1.1.4 (C#) would cut if for my application performance-wise.

Now, this application is a quite performance hungry scientific comptation app wich makes heavy use of vector and matrix operations so the first thing I did was port a sub-set of my home-grown library for this to C#.

The classes use operator overloading to facilitate greater readability in the main code. I then proceeded to implement a fairly simple set of algorithms to test the performance of C#/Mono vs C++. Although I did expect some sort of overhead and slowdown in C#, I was quite surprised and discouraged to find that overall, compiled C++ was faster than Mono's JIT by several orders of magnitude (i.e. 0.018s vs. 1.2s). As is well-known, in theory a good JIT should be able to handle some things better than a static compiler can - and I expected this to be the case with Mono's JIT as well, so to at least lessen the performance impact somewhat.

Now, I have seen what Sun has been able to do with their JIT compiler the last couple of years. I many cases Java code executing under their JIT will have a acceptable (small) overhead compared to native C++ code - and the productivity increase of dealing with managed code will more than make up for this. Unfortunately, the powers-that-be in the Java language community decided to ban operator overloading, apparently because it can be mis-used. As if one cannot create functions that don't do what you would think they do as well :P Be that as it may, enough flames have been traded on this subject in the past; for me, operator overloading is a major point when doing scientific algorithms, so java is not an option.

I started to dig a little to find out why Mono's JIT fared so poorly in my case (which admittedly probably is a fairly untypical use). The reason seems to be that pracically none of the operator overloaded operations were getting inlined. And the objects returned from e.g. a vector addition operation were actually being created instead of being temp-used by the caller (I forget the term for this type of optimization). Also, it seemed that only extremely basic loops/brances would be optimized.

A bit of googling shows that this is a known problem in Microsofts JIT as well. The reason is supposedly the need for a balancing of application-startup and JIT time. Reports pertaining to the new JIT shipping with the newest .Net framework beta indicates that this will still be present in the next version of the MS .Net JIT.

Now, I appreciate that my kind of app is probably on the fringes of what could be considered "a typical" .Net app, but I'm still dissapointed with the performance compared to other JITed languages like, say, Java.

I also tried the Mono AHT compiler with various settings with no significant performance gain for my examples (and quite a bit of slowdown in some cases).

So, end of story; I'm back with C++, with it's irritating - but familiar - quirks and methodolgy. As for now, there still are no other (OO) languages that meets my needs for high performance and language convenience (operator overloading) - and yes, I've looked at Python+Pyrex/Psyco as well.

Hopefully this issue will be address in a future Mono JIT, but I have a feeling it may not be high on the priority list as most "ordinary" apps will not suffer from this kind of problem.

YMM, of course :)