We know that Sun's proprietary Java edition (not the open source one, as that one is nowhere to be found yet) is faster than Mono, but I was surprised that we were so far behind. So I looked at the comparison between Java6 and Mono.
Memory usage wise, we mostly come ahead, but in performance, there were two places where Sun's server VM beat Mono seriously in performance (5x or more), one is the regex-dna test and the other one is pidigits test.
The regex test is a test of the regular expression matching engine in the class libraries, not really a test of the language or VM performance, but library implementation. Clearly, our Regex implementation could use some work.
The pidigits test was showing up as 6x better with Java than with Mono. But the test is basically comparing C# vs assembly language. In Mono's case it is using a full C# implementation of BigInteger while the Java version uses the C/assembly language GMP library that has been tuned with hand-coded assembly language.
I ported Java's pidigits to C# to also use native GMP, and the results are promising, we now have a 4.7x speedup and the process size is one megabyte smaller. I was unable to test the Java version on my machine, as I could not find the native "libjgmp" library.
I wonder what the policy is for the language shootout to use external libraries. If its ok, I should contribute my port, if its not, the Java test should be rewritten to be a fully managed implementation.
If you run all the tests the gap between Java and Mono goes from 8 places, to 3 places; If you remove the two bad tests (Our Regex implementation, and the pidigits test) Mono is only one slot behind Java server; and if you also account for memory usage (but still account for all the tests), Mono comes ahead of Java.
Of course, we got homework to do: why is our Regex implementation so much slower?
Update: As it turns out, Mario Sopena pointed out that, another 25% performance improvement can be achieved if the implementations are similar. The C# sample does a lot more regex work than the Java implementation does. The Python implementation has further refinements on the algorithm that could improve the performance further.
It is interesting to see in the benchmarks the progression:
There are a few rarities, like Fortran being in the same tier as Java and Mono, which probably means the tests for Fortran have not been tuned up, I would expect it to be in the same tier as C.
Also, am surprised by Ruby being the last on the list, I expected it to be roughly in the same range as Python, so I suspect that the tests for Ruby have not been tuned either. Update: my readers also point out that Ruby 1.9 will improve things.
Update: I just noticed that Eiffel is on the first tier, performance wise, but has pretty much all the properties and features of the third tier (garbage collection, strong typing, bounds checking). This means that you get the best of both world with it (and Eiffel's compiler is now also open source).
And of course, at the end of the day, what matters is how productive you are writing code in a language. The Wikipedia is powered by PHP, Amazon by lots of Perl and C, Google uses Python extensively, and the stellar productivity that can be achieved with Ruby on Rails is hardly matched. So even if your language is slower than the first few tiers, to many developers and sites deploying software what matters is productivity.
Choosing between Mono's C# and Java, both languages being roughly on the same class, is a function of the libraries that you use, the ecosystem where the code will be developed/deployed and to some extent the language.
Alvaro's teammates at Sun have a difficult challenge ahead of them when it comes to the language: how to fix a language that has been so badly bruised by their generics implementation, their refusal to acknowledge delegates, the ongoing saga over the catastrophic closure proposals  and the lack of a strong language designer to lead Java into the future.
So even if we have a slow regular expression engine, we have working closures, iterators, events, the lock and using statements in the language and LINQ.
Of course, I wish them the best luck (in the end, Mono is a language-independent VM, and we are just as happy to run C# code as we are running Java code, which incidentally, just reached another milestone) and we certainly plan on learning from the open source Java VM source code.
Alternatively, you can use Mainsoft's Grasshopper to write C# code, but have it run on a Java VM.
 Am tempted to write a post about the mistakes that both Java closure proposals have. But it seems like it will be a waste of time, it feels like there is just too much hatred/NIH towards C# in that camp to make any real progress.
Posted on 28 Dec 2007
This is a cute hack that I put together today.
For months I have wanted to colorize the output of the compiler for errors. Sometimes in a sea of warnings its difficult to find the error that broke the build with a quick visual inspection.
Most civilized people use IDEs, or even Emacs to build their stuff, but for some reason I end up building from an xterm all the time.
Today I introduced the MCS_COLORS environment variable that the compiler will use to configure its colors, the default. This is the default, witness this high-tech beauty:
My personal default is slightly different, as I use grey-on-black terminals, its more of a DOS-days Turbo-Pascal kind of color scheme for errors:
This is my personal setting:
Am not making this the default, it seems too strong for public consumption.
If you absolutely hate this, you can use:
Posted on 21 Dec 2007
Since then, MonoDevelop has progressed to the point where it can generate standard Unix makefiles and generate the proper scripts, pkg-config files and produce code that conforms to the Mono Application Deployment Guidelines from a Visual Studio solution.
It is now easier than ever to try Paint.NET on Linux, all you need is:
To build it, use the following steps:
$ svn co http://paint-mono.googlecode.com/svn/trunk/src paint-mono $ cd paint-mono $ ./configure $ make $ make install
To run, just type "paintdotnet" on the shell, this should come up:
I have not spent much time porting the SystemLayer.dll, but it is enough to access most features in Paint.NET. A real method-by-method audit needs to be done for the port to be considered complete though.
We are calling it "Mono Paint" as the authors of Paint.NET have requested us that we do not use the same name for the porting effort. The idea is that eventually the port will merely be a drop-in replacement for the "SystemLayer.dll" the library where all the OS-specific code is located.
For more details on downloading it, filing bugs, or tracking the project, see the paing-mono's home page at Google Code.
Posted on 21 Dec 2007
I have been re-reading his blog in fascination in my spare time, but this caught my attention:
Ever since I joined up with the C# team nearly two years ago I've been frustrated by my inability to wax poetic about all the goodness we were working on. I was sworn to secrecy. Mum was the word. Perhaps if you were paying attention to the work in C# 2.0 and C-Omega, you may have guessed what was to come. Looking back, it's easy enough to recognize it in the design of Generics, Iterators and Anonymous methods. The existence of Nullables in there as well should have made it obvious. We were planning ahead for the big pay off, language integrated query.
You may be amazed that so much planning goes on in the features that we roll out version to version. Sometimes big ideas and far-reaching visions take many releases to come to fruition. You cannot always do them in one release. Sometimes you have to take a risk and dole them out piece by piece. This may cause a bit of confusion at first, when no one can truly understand why a particular feature was included and not others, or why one design was chosen. Yet once all the pieces are together you can finally make sense of it all, and then as if by magic it all just seems right.
At some ECMA meetings in 2004 (the time stamps for some of my notes on the disk are January of 2004) some of the new features were being presented at ECMA and it was obvious to see the benefit for those features (generics, check; anonymous methods, check; iterators, check; partial classes, check) but a few of the features made no sense.
Nullable type decorations made no sense to me ("int? a"). I remember feeling that they were pure compiler bloat and that the use case of databases made no sense. Am not a database developer, but I felt that the syntactic sugar at the time really was not bringing much to the plate. During one of the meetings, I remember putting together a parody for new type qualifiers (which is the timestamped file I kept) for other domain-specific features that I felt were just as useless.
Even with early access to the C# 2 specification for so long, I did not see these components coming together and fitting perfectly to create LINQ.
Posted on 19 Dec 2007
Nat just landed, and we were touring the office when we ran into a messy room.
Nat: what happened here?
me: Oh, that's the xbox room.
me: but the xbox is not here now.
Nat: so what do you call this now? "The room"?
Posted on 18 Dec 2007
After the world acclaimed announcement of gui.cs eight months ago the developer user base has doubled!
That is correct. We now have 2 (two) applications using the awesome gui.cs rich-console-application development platform to deliver the best ncurses has to offer to all those vt100-derived emulators:
Although I had a great testimonial from my first user, it was not suited to be printed on a family blog.
Posted on 18 Dec 2007
You can still send me your information, I will likely help the guys doing the interview, but the actual HR-esque process that organized people at Novell use is available.
Again, these are not a jobs in the Mono team, but in the desktop team although plenty of the code that you will write will end up in the standard Mono distribution.
Posted on 17 Dec 2007
Reddit-poll after reddit-poll has shown that am most closely aligned with Kucinich than any other candidate for president of the US. Read the summary of his positions:
More details: here.
Posted on 14 Dec 2007
We are doing some work to make Windows.Forms and Moonlight accessible. The desktop team is hiring people for the Cambridge office (USA) that want to work on accessibility technologies, free software, C#, Mono and the UI Automation framework.
Although a lot of the work will end up in Mono, this is part of an effort from the desktop team, so technically you will be reporting into a different organization than the Mono team.
Posted on 14 Dec 2007
My dear friend Chris Toshok recently discovered that he had developed diabetes.
Tomorrow he is going to be admitted into an experimental treatment program for it. He will undergo four days of treatment.
The day that he told us about the experimental program, I had just seen this:
Good luck Chris!
Posted on 12 Dec 2007