sutton037

The Raspberry Pi uses an older ARMv6 core which is not well supported by modern software. In particular, Mono's JIT apparently doesn't support the hardware-accelerated floating point instructions used by that version of the ARM instruction set. The solution is apparently to use the soft-float version of Raspian that emulates floating point instructions in software (which will be extremely slow). However, trying to compile the current version of the F# sources on Github using the stock Mono (2.10.8) fails with the following null reference exception from within the F# compiler: error FS0193: internal error: Object reference not set to an instance of an object Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object   at Microsoft.FSharp.Core.FSharpFunc`2[Microsoft.FSharp.Collections.FSharpList`1[System.String],System.String].InvokeFast[CcuThunk] (Microsoft.FSharp.Core.FSharpFunc`2 func, Microsoft.FSharp.Collections.FSharpList`1 arg1...

We previously complained about the use of Boehm's conservative garbage collector in earlier versions of Mono because it is fundamentally flawed and prone to causing unpredictable memory leaks that result in applications dying with out-of-memory errors when there is plenty of garbage left to be reclaimed. Specifically, we gave a simple 9-line example program that fills and forgets ten hash tables that ran out of memory when run on Mono 2.4. What happens when this program is run on Mono 2.8 using the new SGen garbage collector? Running the test with Mono 2.8 using the default Boehm GC often reproduces the same leak that we saw before, as expected. Repeating our previous test using the new SGen garbage collector we find that the program does not die after four iterations with an out-of-memory error but gets as far as eight of the intended ten iterations before dying with a segmentation fault: $ mono-sgen Tail...

How fast are hash tables in Mono 2.4 compared to .NET 4? An excellent question but one which led us to another trivial program that leaks memory on Mono but not on .NET (we previously gave a simple stack implementation written in F# that leaked memory on Mono 2.2 ). We tried to use the following benchmark program to measure Mono's performance when filling a hash table from empty with float keys and values: for i in 1..10 do let t = System.Diagnostics.Stopwatch.StartNew() let m = System.Collections...

Miguel de Icaza of the Mono project made two surprise announcements in a recent blog post : "We are working to improve our support for F# and together with various groups at Microsoft we are working to improve Mono's compatibility with the CLR to run IronPython, IronRuby and F# flawlessly in Mono. Supporting F# will require some upgrades to the way that Mono works to effectively support tail call optimizations." "we continue to work on integrating LLVM [better use LLVM to produce better code, use it in more places where the old JIT was still required and expand its use to be used for AOT code]" We have been pushing for these developments (F# support and an LLVM backend) for over a year now and it is very exciting to hear that the Mono team are taking this seriously. F# is the future of .NET and building upon LLVM offers huge potential not only for improving upon the performance of Mono's code generator but also in improving LLVM itself, which is now the ...

We have previously discussed the fact that Mono is still built upon a conservative garbage collector (Boehm's GC). This means that Mono is not capable of identifying exactly what data is reachable and, consequently, has to resort to conservative guesses that can fail to deallocate garbage, i.e. leaking memory. Boehm's own literature describes situations where the GC might be expected to leak (lazy lists and queues) but claims that no case has even been found in practice and they could not even construct a contrived example where memory was actually leaked. Readers of our previous posts have stated that our claims of memory leaks are "bogus". So we decided to put this issue to rest. The following trivial F# program creates a cyclic list representing a queue, adds one element and then repeatedly adds one element and removes it again: type 'a cell = { content: 'a; mutable next: 'a cell option } do let mutable tail = None if tail = None then let cell...

Tail call elimination is an essential feature for functional programming languages. This feature simply refers to the ability for one function to end with a function call without leaking stack space. Tail call elimination can be essential in heavily functional code such as parser combinators and libraries written in continuation passing style. Lack of tail calls on the defacto-standard JVM has raised concerns around languages like Scala and Clojure. Fortunately, work is underway to address this issue by implementing tail call elimination on MLVM/OpenJDK. Microsoft's .NET has had tail call elimination for eight years and the Mono project is designed to replicate the Common Language Infrastructure (CLI) that is responsible for this feature. The Mono team have been advertising tail call elimination on their VM for many years. However, when we tested the elimination of tail calls on several VMs we discovered that tail calls are seriously broken on Mono but work on other VMs including ...

Mono 2.2 was recently shipped and a new JIT code generator was the main selling point promoted by the Mono project because it provides the first significant performance improvement Mono has seen for many years. We used the F# version of the SciMark2 benchmark to benchmark this new version of Mono against Mono 2.0 and some competing VMs using their native SciMark2 implementations: The composite results show that the new code generator in Mono is indeed substantially better at producing code that is 40% faster on average than the previous code generator from Mono 2.0 according to these results. However, Mono 2.2 is still a long way behind its competitors. Specifically, both LLVM and Sun's JVM are over 2.2× faster than the latest version of Mono. SciMark2 is composed of five different tests: Fast Fourier transform, successive over-relaxation, Monte Carlo, sparse matrix-vector multiply and LU matrix decomposition. We can get more detailed comparison of the VMs by looking at the indiv...

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 t...