The Jesus General proposes some updates to the amendments.
The comments section has some great suggestions as well.
Posted on 28 Jan 2006
The Mono team is working on a number of directions to improve code generation. Although Massi has worked on a number of advanced optimizations to improve code generation (based on SSA and HSSA), the improvements were dominated by problems on the register allocation.
We are working in two directions to fix this issue. A long-term fix is the new linear IR representation which Zoltan is working on. This code today is available in the mini-linear-il branch on SVN. The intention of this new IR is to improve the visibility of register usage to the register allocator, so it can make better choices when producing code.
A second line of work emerged from our research into inlining. Turning on the Mono inliner produced worse code than not turning on the inlining at all (we have it turned off by default on Mono). The problem was that inlining produced plenty of local variables and the resulting IR became very hard to optimize by the higher layers of the JIT engine so Massimiliano devised a plan to eliminate these extra temporary variables.
The details of this new optimization can be found on his mailing list post "Tree Mover".
What follows are a few excerpts from the email. Consider this piece of C# code:
private int f;
public int F {
get {
return f;
}
set {
f = value;
}
}
static int Inline (int a) {
return a * 4;
}
public override int Cprop (int v) {
return Inline (F + v);
}
The IR produced with the method "Cprop" is this:
(outarg (ldind.i arg[0])) (stind.i4 local[2] call[get_F]) (outarg (add (ldind.i4 local[2]) (ldind.i4 arg[1]))) (setret call[Inline])
The problem happens when we inline the call to "Inline", which turns the IR into this:
(stind.ref local[3] (ldind.i arg[0])) (stind.i4 local[2] (ldind.i4 (add (ldind.ref local[3]) iconst[8]))) (stind.i4 local[4] (ldind.i4 local[2])) (stind.i4 local[6] (add (ldind.i4 local[4]) (ldind.i4 arg[1]))) (stind.i4 local[5] (mul (ldind.i4 local[6]) iconst[4])) (stind.i4 local[4] (ldind.i4 local[5])) (setret (ldind.i4 local[4]))
The extra variables introduce the extra pressue on the register allocator, which today produces pretty bad code (see Massi's original post for the details).
What Massi's new tree mover code does is remove the unused local variables from the previous representation:
(setret (shl (add (ldind.i4 (add (ldind.ref arg[0]) iconst[8])) (ldind.i4 arg[1])) iconst[2]))That is a much better tree to cope with in the code generation phase, and produces nice and compact assembly code.
Read his post "Tree Mover" for details for the actual assembly code produced before and after and benchmark information.
Posted on 24 Jan 2006
Ankit Jain which maintains the Mono IL assembler has started a blog here.
He is currently working on adding generics support to our assembler and disassemblers and working on roundtripping the assemblies (the process of disassembling and reassembling the libraries and obtaining the same binaries).
Posted on 17 Jan 2006
Lluis blogs about his recent work to integrate the Glade-3 GUI designer into MonoDevelop.
With his recent changes you can maintain your Glade-based UIs from within MonoDevelop: changing properties of widgets, manipulating your UI and the best bit is that whenever you add a new event handler it automatically adds the stub of code to the C# file.
You can see a screenshot in his post.
Posted on 15 Jan 2006
Mono supports a number of platforms, Windows included. For us, supporting Windows is important because it helps us debug our code, helps ensure that we are doing things portably, and is useful to test applications on Mono in Windows and contrast it with .NET on Windows.
Today on the mono-list someone mentioned another use of Mono on Windows (as part of a bug report), which made my day:
It's reasonable to ask why someone should be interested in running Mono on Windows when the original .NET is available. My reason is that Mono applications can be run without an install. .NET requires a lengthy installation (and a reboot with 1.1 SP) that many administrators (if not users) will not consider. Mono can be copied on (or even run from a memory stick).
It is not every day that you run into reasons to run an open source implementation of a Microsoft standard on a Microsoft operating system.
In the mean time, in another side of the universe Neale completed the 64 bit port of Mono to the S390x. It is part of Mono 1.1.13.
Aaron posted an update on his work on Banshee, the awesome Mono-based music player that ships with SUSE Linux.
Congratulations to the Imeem folks for shipping their Imeem Client for OSX.
Imeem is the second commercial Mono OSX application that ships.
Posted on 11 Jan 2006
I just woke up to the announcement over at Chris Blizzard's blog (from Planet Gnome) that Mono today was included in Rawhide, the staging area for the next release of Fedora Core.
These are fantastic news for Mono users and developers everywhere and for Fedora users which will get both Mono and the various Mono-based applications that have been cooking.
Am looking forward to work together with the Fedora folks.
If you are a new Mono user, here are some useful links:
Posted on 10 Jan 2006
The Jesus General posts a few profiles from the documentary Persons of Interest.
The "Reports to the General" over at the Jesus General are always fun, make sure you check them out.
Reminds me of what Molly Ivins said about vegetarians.
Posted on 04 Jan 2006
I found this quote from historian Howard Zinn insightful:
There is a persistent argument against such a possibility, which I have heard from people on all parts of the political spectrum: We will never do away with war because it comes out of human nature. The most compelling counter to that claim is in history: We don’t find people spontaneously rushing to make war on others. What we find, rather, is that governments must make the most strenuous efforts to mobilize populations for war. They must entice soldiers with promises of money, education, must hold out to young people whose chances in life look very poor that here is an opportunity to attain respect and status. And if those enticements don’t work, governments must use coercion: They must conscript young people, force them into military service, threaten them with prison if they do not comply.
Emphasis added.
He follows up with assorted examples.
Posted on 31 Dec 2005
Recently Nitesh Dhanjani in a bit of a rude email exchange asked Steve Jobs if he had plans to support something like .NET or Ruby on the Mac.
Update: On a positive note, Nitesh's blog entry has sparked an interesting discussion.
Given the initial confrontational exchange (which can be found here) am not surprised at Steve's immediate comments.
I would like to add some comments to the discussion as we develop a cross platform Common Language Infrastructure (CLI) implementation that also supports the Mac.
Steve claims that ".NET with CLI and managed code runs SLOW". It is true that writing code in a managed language or an interpreter is likely going to be slower than the output produced by a C compiler, or the output produced by hand-tuned assembly code.
Lets start with an example: F-Spot is our photo management software which is written in C# and runs on the CLI consistently outperforms iPhoto and scales easily to hundreds of thousands of pictures without the obnoxious pauses that are common in iPhoto for example. F-Spot gets bonus points for being written by a single developer.
F-Spot makes use of a feature in the CLI called "Platform Invoke" (or P/Invoke) which allows code written in a managed language to call into native code easily. In F-Spot's case all the high-level logic is implemented in a managed language and the bits that are performance sensitive (like quickly rendering the image, transforming JPEG images and even the GUI toolkit employed) are implemented in C.
From a productivity stand point this is the best of both worlds: programmers can use a higher-level language to focus on the functionality first. When they identify a performance bottleneck they can easily move this functionality into a C library.
It is possible that Steve has only looked at Microsoft's Rotor implementation of the CLI which merely ships a toy code generator. We encourage them to look at Mono and the various new advanced optimizations that we are introducing in Mono.
Although raw performance is good for some applications they impose a heavy toll on the developer. A professionally written and hand tuned assembly language program will likely perform better than anything else generated by a compiler.
The language and runtime choice is a tradeoff that developers make. A balance between the time available for releasing the product; the budget available for creating and maintaining the application; the target system requirements; any third party libraries and components required; the in-house expertise; availability of developers with knowledge to develop and maintain the code; language learnability; the project life-span and the requirements that it might impose on the project: from languages designed to maintain software over a large period of time to write-once, barely-touch-afterwards software.
There is not a single solution to the problem of course, but we believe that Mono does bring a good mix of elements that make it a good choice for a large body of developers. Some people will continue to be happy with their existing tools and their existing frameworks, but I believe Mono can help Unix developers produce better applications faster.
Mac developers interested in using Mono and its tools on the OSX could use the Cocoa# bindings today. It is not complete, but it has a good foundation on which people can add more bindings to Objective-C libraries.
As a project maintainer, am interested in learning what Cocoa# and Mono are missing for developers on the OSX platform.
I know that OSX developers in the past have asked for Mono integration into X-Code, this is an area where collaboration between Apple and Mono would be useful. Alternatively there is the X-Develop IDE by OmniCore and eventually when the next version of Gtk+ ships with Quartz support we will likely ship MonoDevelop for OSX as well.
Another advantage of Mono and the CLI is that it becomes easy for existing developers that have been targeting .NET to target new platforms.
This is just a pragmatic point. Developers can reuse a large body of their expertise, their books, their documentation, their connections to bring their software to Unix. Some things might have to change to work effectively on Unix, but porting an application from Windows to Unix is no longer a multi-month or multi-year project.
Porting an application from .NET to Mono is similar to porting a Unix application from SystemV to BSD: there are a few differences, but they make up only a tiny fraction of the application.
The CLI was designed so it could host efficiently any programming languages in use today, but it also contains a strong interoperability layer. I already mentioned P/Invoke which Mono supports, but the framework is complete enough that it is possible to also integrate other object systems easily into the system. Today we have done this with Gtk's GObjects and some volunteers are working into adding COM support to Mono.
The languages story is a powerful one.
The CLI defines a set of language interoperability requirements which every language should adhere to (these guidelines are called the "Common Language Specification"). By following these guidelines once an API is developed in any of the CLI languages the API becomes available to every other language.
Apple has struggled in the past in maintaining two code bases: one for Objective-C programmers to develop GUI applications and another one in Java.
It is understandable that they do not want to support every single one of their APIs for every programming language out there; otherwise their own development would slow down, it is just not possible to do so.
This is where I think the CLI adds tremendous value. Today developers only have to "bind" the API once and it becomes available to all the languages in the CLI ecosystem.
Consider Geoff's effort to bind Cocoa. The Cocoa bindings that Geoff has hand-written are now available to all of the programming languages that target the CLI. Apple developers can use this API and any of the other CLI APIs developed by .NET and Mono developers on their applications with their favorite programming language: Boo, Nemerle, C#, JavaScript, Java and more.
There are a number of ways in which a language can participate in the CLI ecosystem. The most common one is to have the compiler translate the source language into CLI byte codes. This requires the creation of a compiler that targets the CLI.
Examples of some open source compilers in this group include: C#, Python (with the IronPython compiler), Java (with the IKVM compiler), Nemerle and Boo. In addition to this there are several commercial compilers available: Fujitsu's Cobol compiler, ISE's Eiffel, RemObjects, Microsoft's own Managed C/C++ and many more.
In some cases it is easier to write a "bridge" than to write a new compiler. This reuses an existing implementation and merely bridges the calls between the existing language and the CLI universe.
Bridges have been developed for Python (yes, this is a parallel approach), Perl, Ruby and OpenOffice's UNO (this is how we are able to script OpenOffice using Mono). There are more, but I do not keep track of these.
In addition Mono provides an embedding interface which allows developers to embed the virtual machine into an existing application. OpenOffice Mono integration (available in OpenSUSE 10), the game Second Life and the Unity game engine all use this embedding interface.
As I mentioned before, I do not believe that Mono is an ideal solution for every kind of application; Like every other framework Mono also has its own limitations and features missing; Its up to every developer to make this choice. But we believe we got a very solid mix.
One Mono's goals is to work-well-with-others. Working with ISVs to ensure that their software runs with Mono and Unix is one of the things we take pride in doing. We always welcome new collaborations on the Mono universe.
Update: Erik also comments.
Posted on 28 Dec 2005
JB Evain announced Cecil 0.2 the CIL image manipulation library.
Thomas from Fluendo announced that they have licensed the MP3 decoding for use with their LGPL libraries. Details are also here. There are a number of licensing caveats, you should check them out.
Banshee, our new media player, was licensed under the MIT X11 terms explicitly to avoid these issues (Banshee as shipped in Novell's Linux editions uses the RealPlayer framework for its playback).
Posted on 24 Dec 2005