Wednesday, 8 October 2008

Mono 2.0

The Mono Project was intended to bring the benefits of Microsoft's excellent .NET framework and, in particular, the Common Language Run-time (CLR) to other operating systems such as Linux and Mac OS X. The home page even boasts that Mono is "positioned to become the leading choice for development of Linux applications".

If Mono provided a solid foundation then it could well become the platform of choice on systems like Linux but the 1.x implementations have been plagued by reliability and performance problems.

Firstly, the design and implementation of a performant concurrent garbage collector is the single most difficult of the platform's core features to implement but is of absolutely critical importance. The implementation of a real GC for Mono was originally postponed and the Boehm GC was used instead, being described as an "interim measure" over 5 years ago. The Boehm GC is fundamentally flawed in this context, leaving programs to leak memory until they are killed by the OS.

Secondly, Mono's code generator generates native code that is slower than almost all other compiled languages.

Five years have passed since then and Mono 2.0 has just been released but, contrary to previous announcements, this new version is still built upon Boehm's flawed garbage collector and our SciMark2 benchmark implementation in F# shows that Mono 2.0 is still 3× slower than .NET for numerical algorithms.

So Mono appears to be no closer to its goal of being the leading choice for development of Linux applications. This begs the question, how might Mono development be improved in the future? Failing to implement a working GC for Mono forced the Mono developers to spend a great deal of time and effort fixing bugs and addressing performance issues related specifically to the Boehm GC that, in the grand scheme of things, are worthless because that GC was only ever a stop-gap measure. Mono originally reinvented the code generator because mature reusable alternatives like LLVM were not yet available. However, the most difficult aspect of implementing a code generator for Mono is maintaining harmony with the GC but Mono still lacks a working GC so there is no harmony to be maintained. Consequently, it seems logical that the Mono developers would be wise to adopt the LLVM project to handle their code generation (because it already provides much better performance) and then continue trying to build a real GC for mono in harmony with LLVM-generated code. In fact, other projects such as PyPy are progessing so much more rapidly than Mono that they may be the first to provide a complete backend.

Hopefully the Mono project will provide the solid foundation that it intends to in the future but, in the mean time, we shall restrict ourselves to the use of robust garbage collectors.