Mono 2.8 Is Out With C# 4.0, Better Performance

[movieman]

Fair enough but COME ON, Gnome is *not* pushing Mono. That's ridiculous!

If a Mono application is part of the offical Gnome release, how can Gnome not be pushing Mono? I wouldn't have Mono installed on my PC at all if it didn't come with Gnome; I'm guessing there's probably some magic I can do to uninstall the Mono-reliant parts while keeping the rest but now it's installed there's not much point spending the time to figure that out.

[kraftman]

You need to refresh your memory: Mono is currently using Boehm GC which is one of the best collectors written in C++. Saying that it sucks is preposterous.

But maybe its implementation in mono sucks? Or it doesn't play well with mono?

[monraaf]

It's not integrated in GNOME, just some easily replaceable apps. And distros are free to ship without Mono. AFAIK Fedora doesn't ship with Mono installed by default anymore. Ubuntu has Mono for Tomboy and some silly game. A sudo apt-get purge mono-runtime takes care of that.

[makomk]

But maybe its implementation in mono sucks? Or it doesn't play well with mono?

Boehm is actually a very good garbage collector for what it was designed for - adding garbage collection to C and C++ programs that use garbage collection selectively and avoid using it for lots of short-lived objects. Mono developers and supporters, including Miguel de Icaza, have been trying to spin this as meaning that Mono's garbage collection is good. In reality, the Boehm GC is totally inadequate for something like the CLR where almost everything is garbage collected and there's no way to avoid using the GC.

[BlackStar]

Boehm is actually a very good garbage collector for what it was designed for - adding garbage collection to C and C++ programs that use garbage collection selectively and avoid using it for lots of short-lived objects. Mono developers and supporters, including Miguel de Icaza, have been trying to spin this as meaning that Mono's garbage collection is good. In reality, the Boehm GC is totally inadequate for something like the CLR where almost everything is garbage collected and there's no way to avoid using the GC.

Agreed. As far as I know, Boehm had two main issues:
a) it's not generational, which means it cannot separate short-lived objects from long-lived objects (which causes the issue you mention)
b) it's conservative, whereas the CLR is designed with exact/intrusive GC in mind (it is actually possible to collect an object while it is executing code!)

In the end, Boehm could not be made to track dead objects reliably and quickly and a replacement had to be created. The performance pitfalls in Mono are well-documented and with shops/servers increasingly moving from Windows to Linux something had to be done. Unfortunately, this is not some weekend project, the implementation details are insanely complicated - and fascinating if you are into that short of thing: how to find safe points to suspend thread execution, how to scan the object graph, how/when to collect and compact the memory - but this is man-years worth of work.

Historically, both Mono and Portable.NET started out with Boehm, so there must have been some contributing factor to this decision.

Still, with the number of people using Banshee and F-Spot and the like, it would suck really hard for them if those things got killed or went proprietary.

Well, it's not as if we are actually hurting for replacements: Rhythmbox, Exaile, Amarok, Pogo, XNoise, Shotwell, RawTherapee, ...

[pingufunkybeat]

If you have your entire music and photo collection tied to those apps, then it might be a bit of a pain in the behind.

But yeah, this is why having options is healthy.

[Silverthorn]

If you have your entire music and photo collection tied to those apps, then it might be a bit of a pain in the behind.

But yeah, this is why having options is healthy.

That's a good example why open source is so important. It allows a program to read the garbage from a completely different application. Err, I mean 'output' not 'garbage' . At least an open file format can always be re-implemented somewhere else. Also algorithms can be reused and translated to other languages. Not everything would be lost.

[NoEffex]

the point of free software is choice. So, by preventing users from using applications the way they want to or what software they want to is thereby making it non-free. It might be open but it's not free. That's why I dislike the GPL, although I do like what it's intentions were.

Basically, what I'm trying to say, is that by restricting users from certain applications or advising against it is hypocritical. By calling all software that's closed evil is hypocritical. The whole point is to get back contributions from the community. I DARE you to offer a contribution. You will promptly be flamed. It's not worth your time.

I gave up on the FOSS community because it's largely populated by egotistical people who refuse to accept any innovation (i.e. FatELF for one) and flame anybody who tried to contribute. Now, the most successful projects are led by people who aren't part of the majority (Keith Packard), and people like Linus are excusable because of the nonsense they've dealt with.

The FOSS community needs a massive attitude adjustment, and high horses need to be gotten rid of if anything were to happen. Unfortunately I don't see that happening so yeah.

[insane74]

1) as a MS developer (at work), i'm glad to use my C# skills in linux (at home) since I simply LOVE linux. i'm very happy to have this opportunity

2) afaik, some sue someone when someone has money. who MS should sue? "linux"? who is "linux"?

3) mono has quite good performance:
- mono vs python, up to 236 times faster: http://shootout.alioth.debian.org/u3...&lang2=python3
- mono vs java, from 2 to 16 times faster http://shootout.alioth.debian.org/u3...lang2=javaxint
- mono vs c++, from 2 to 10 times slower: http://shootout.alioth.debian.org/u3...lang2=javaxint

i think that for a young implementation of "someone else" tecnology, performance are really good.

[igouy]

3) mono has quite good performance:
- mono vs python, up to 236 times faster: http://shootout.alioth.debian.org/u3...&lang2=python3
- mono vs java, from 2 to 16 times faster http://shootout.alioth.debian.org/u3...lang2=javaxint
- mono vs c++, from 2 to 10 times slower: http://shootout.alioth.debian.org/u3...lang2=javaxint

No. You have compared mono to interpreted Java!

- mono vs java, from a tiny bit faster to 5 times slower

http://shootout.alioth.debian.org/u32q/csharp.php

- mono vs c++, from 2 to 10 times slower:

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=csharp&lang2=gpp