Updates to the production
and development
versions of Mono have been released. The major features of this release are:
- Generics support in the compiler is now feature
complete. Use the bundled Mono.C5a
library to explore the generics world. Couple more features from C# 2.0 are implemented. - SSAPRE optimization engine: for your performance
needs. - New simplified build system, single `make’
compilation of C and C# sources. - New and improved Mono.Unix namespace.
- Faster, leaner, stabler everything.
- .exe files are now gone from your /bin directory.
Awesome! I would like to try and write an application in Mono/GTK# one of these days(file manager), it is great to see that it is shaping up.
Kudos to Mono team. Handling C5 must have been really a stress test for generics implementation.
Is there a similar library for .Net with functional data structures?
I’ve been a .NET fanatic for 4 years now, I’m trilled that it’s maturing for *nix!
I’m *really* waiting for performance to improve considerably before using Mono in production at all. According to the benchmarks that came out a while back (.NET vs. Java) Mono was quite a bit slower on the server-side, coming in slower than Java or .NET.
I’m sure that’s due to XSP.
Yeah, I think that the download section is better organized, except some people will wonder if they have to install both:
mono-core-1.0.5-1.novell.8.3.i386.rpm
mono-devel-1.0.5-1.novell.8.3.i386.rpm
Or do you just need one or the other. At any rate, I think it’s installable now, so that’s a big improvement.
They should also sell an official Mono 1.x guide, which covers all of the basics of Mono 1.x capabilities. It just has to cover all of the basics and most used classes and ways to use Mono. Than when Mono reaches version 2.0 they need to do another official guide, but there should be at least 18 months or 24 months between major releases. I like how GTK is doing this with their official guide, it’s all you really need for open source development libraries.
PHP running on top of .NET link!
http://numbers.wordnerd.org/blog/index.php?p=19
Damn, I still failed to install it. I don’t understand where to get all the dependancies. I can install Java though.
I compiled the new package with –prefix=/usr and it worked out of the box, great work and I really like C#
XSP is awesome for quick development.
Anon: What deps are you lacking?
I am afraid it is not mature at all. The garbage collector performance is very poor (in comparisn with MS’s implementation or current java GC). Yes, it’s better in 1.1.x but still insufficent for large data-manipulating apps (e.g. Beagle).
Another disaster are database connector. Especially connector for MySQL – it crashes under high load. And my attempt to use unixODBC with mono didn’t give better results.
I like C#, but today it’s pleasure under windows and stress under Linux
Anyone know why there are no packages available for Fedora Core 3 yet? I’m guessing it’s a case of it being just released etc.
umm
mono is a good platform but there are too many inconsistent libraries
for example the best application written in mono is beagle but depends
on dbus-sharp (instable )
Lucene.NET (unmaintained unstable )
evolution-sharp (unstable )
gecko-sharp (unstable )
gsf-sharp (unstable )
I am afraid it is not mature at all. The garbage collector performance is very poor (in comparisn with MS’s implementation or current java GC). Yes, it’s better in 1.1.x but still insufficent for large data-manipulating apps (e.g. Beagle).
The GC should really be working fine for relatively large apps. One of the things I am looking into is what improvements we can make on today’s collector. As you mentioned, some huge improvements are in the 1.1.x series (and by huge, I mean `very, very noticeable’).
Sometime durring the 1.1.x development timeline, I will probably look at some specific Novell apps (Beagle and iFolder) to see what Mono can do to help them out. Also, large programs like this are breading grounds for memory retention problems (which essentially manifest themselves as leaks, though they technically are not, since we keep a pointer around). Fixing a memory retention problem in XSP gave us huge benefits a few releases back.
One thing that I should note is that many of our problems are not in the gc, but in unmanaged memory, both that of the runtime and that of gtk/glib/et al. Running an application like Monodoc, the GC heap is smaller than the amount of memory valgrind is reporting as being retained. And the valgrind statisitc is low, as it does not take into account heap fragmentation, etc.
Try running an app with the env variable `GC_PRINT_STATS’ on. It tells you how large the GC heap is at that time. This takes memory fragmentation into account, it is the number of bytes the GC has malloc’d for it’s heap, not the number of blocks active at that time. IIRC, Monodoc was in the 1 MB range for this. Consider that running zenity –info (shows a small dialog) keeps 500 kb of memory allocated. This is with the latest CVS using jhbuild, on the packages that come with NLD, it is much higher (many improvements have been made. For example, a few days ago, a change to Fontconfig was made that saves 90 kb per gui process, a huge benefit). And that was just a dialog with an icon, a label, and a button. I don’t have the monodoc numbers in front of me, but I am pretty sure that the memory allocation in unmanaged code was much larger than that of managed code.
Another expariment I did was to bootstrap mcs on running on windows with msft and on linux. Using the clrprofiler on windows and GC_PRINT_STATS on Linux, I noticed that the gc heap size was very close (within a few MB). MCS bootstrap is a huge memory allocator, so it is a fairly good test (it allocates about 50 MB of gc memory over 3 seconds).
But that is about memory footprint, not about performance. To test perf, try running with GC_DONT_GC set. This will completely disable collection. For practical purposes, this is as much performance as we could possibly get out of the gc (We might be able to get a few more % because of memory locality, otoh, the gc will never have 0 cost, so those two slash out). The last time I checked, this gave me only about 10% on mcs bootstrap. So that is an effective upper bound on the amount of benefit we can get.
Most of the benchmarks refered to in the origional post are very outdated. I have not seen one since 1.0. None have been run on the 1.1.x series, which is much better than 1.0. There are apps running on mod_mono today that work *just fine*.
Not to mention, by running on Mono, you will get a free speedup in your app every year. Every time you install the next version, you get a *free* speedup with *0* work. If you are writing code in C, you have to wait for the next version of gcc to get tree-ssa or something. With mono, when you upgrade to 1.2, you will have SSAPRE. You don’t even have to recompile.
I see your point and I agree with you, however I have actually seen companies writing mission critical apps in Mono.
If you think Mono’s dependancies are unstable look at Dot net dependancies (Windows)!
I like mono but I don’t see how it will ever be able to meet its Microsoft counterpart due to Dot Nets dependancies (directx, etc…).
Does it support windows forms? Also is there a version for Mac OSX? If both of these are yes then I will start looking at it next semester for one of my classes.
There is a version for OS X. Just visit the Mono project homepage.
Does it support windows forms?
Not yet. Windows Forms will be supported in Mono 1.2, which is currently expected Q1/Q2 2005.
If you’re brave (or foolish, or both) you can run the CVS build of Windows Forms, called Managed.Windows.Forms. This is completely unsupported and the developers likely won’t respond to requests for help, but it’s (possibly) an option.
Also is there a version for Mac OSX?
This is a rather vague question. Is what available for Mac OS X? Mono certainly is:
http://www.go-mono.com/archive/1.0.5/macos/MonoFramework-1.0.5.dmg
IIRC, that also includes Gtk#, so you can write Gtk# apps now for Mac OS X. Alas, GTK+ requires the X11 server on Mac OS X, so this probably isn’t an ideal solution…
There is also work on getting the Managed.Windows.Forms effort working on Mac OS X without using an X11 Server. See:
http://blog.sublimeintervention.com/pivot/entry.php?id=10
And for those who demand the most native Mac OS X look-and-feel for their apps, there is an effort to bind Cocoa in C#, Cocoa-Sharp. This is currently in the “cocoa-sharp” SVN module.
Thank you. That was exactly the answer I was looking for. Sadly the windows forms support will be too late for next semester but next Fall looks good.
is there any repository for fedora core 3?
I see your point and I agree with you, however I have actually seen companies writing mission critical apps in Mono.
And so how many companies are inviting you in to inspect their development? And even if you are “invited” in and see some programmer writing ASP.NET code in Visual Studio, how do you know that it’s not being deployed on Mono? It’s my understanding that a germany company did a large-scale rollout of a ASP.NET system running on Mono in Frankfurt or Hamburg or something. You don’t even see many .NET shrinkwrapped software at your local store either because most shrink-wrapped developers still target win32.
Mono still has some rough edges, but it’s getting better all the time and there are quite a few developers at least in the Gnome community that love programming with Mono.
I like mono but I don’t see how it will ever be able to meet its Microsoft counterpart due to Dot Nets dependancies (directx, etc…).
directx is not a .NET dependency? Where did you come up with that? Do you even know what directx is? The only big part of .NET that is missing on Mono is Windows Forms and that is being re-implemented without a dependency on Wine by 4 fulltime developers and volunteers. A beta should be coming out later this month.
This is one thing where mono could surpass the microsoft .NET implementation easily, since the microsoft implementation is really bad in this area. Even Rico Mariani says so in his blog.
With the microsoft .NET runtime methods containing explicit struct parameters are *never* inlined. So operator methods on structs and many other very performance-critical small methods are not inlined, which leads to huge (factor 5 to 10) performance losses.
Unfortunately mono does this too, but there is really no reason it should do so.
Agreed here. Especially with List <T>. The generics list has:
public class List <T> {
public Enumerator <T> GetEnumerator () {}
public struct Enumerator <T> : … {
….
}
}
This has the benefit of avoiding the allocation of the enumerator object in the gc heap. However, it also allowes us to transform virtual calls into regular calls.
It would not be hard (in fact, it could be very easy) to make enumerators faster than for (int i = 0; …) on List <T> (we can do better ABC removal). This could also enable us to do SRA (changing the structs into a few local variables), which would allow us to keep things in registers. It would probably be easiest to just hack special support for List <T>, rather than do a full blown SRA.
The s.col.gen would need to be written first, but feel free to make patches. (Btw, inlining is sadly not enabled by default because it is not well tuned, we need to fix this).
It’s my understanding that a germany company did a large-scale rollout of a ASP.NET system running on Mono in Frankfurt or Hamburg or something.
No they didn’t, because Mono and mod_mono is nowhere near good enough to run serious web applications on. At most it was a trial, which is where a lot of this rubbish tends to come from.
directx is not a .NET dependency? Where did you come up with that? Do you even know what directx is?
Herein lies the issue you can’t comprehend. Everybody developing for .Net on Windows will be using a lot of Windows extensions such as DirectX and Windows.Forms (it will never be good enough to be 100% usable, just like Wine) which will ultimately tie them to Microsoft .Net and Windows. This will get worse as time goes on to the point where porting to Mono will really be some effort (it already is at the moment). The Mono developers will then have to make some serious decisions about replicating the Windows technology extensions people will be using, or accepting that following Microsoft was pointless in the first place.
That’s one of the fallacies that people just don’t get about Mono.
no just kidding
i like anyone else have no right to criticize
if I am not submitting any code
they did a brave decision dropping wine
yeah it was a big setback and back to square one.
but they’ve worked hard – i like the team.
i can’t wait to see windows.form ready though
i will reinstall mono / mono-develop again and get coding.
how is people’s experience with gtk# ?
can you do stable apps with it (or other libraries)?
just curious.
We’re trying to set up a development group with development systems based on the latest version of Fedora Core. Each time the stable is released, we update our workstations (keeps us sharp).
We’re hoping official Mono packages will be released soon for FC3. Any statements from the mono guys?
If you think the goal of Mono is to be able to run every Windows .net exe files on Linux, then you are right, mono will not be able to realistically be able to do that.
If the point of Mono is to provide a good c# (and clr) environment for Linux, then they will absolutely (and almost have) succeed.
It’s a matter of perspective. And like every other language out there, the portabllity of applications developed in C# (or other supported languages) is up to the developer.
BTW, to me the most facinating element of .NET or Java, is the posibility of running one compiled application, on multiple hardware platforms and Operating Systems. That’s the holy grail to me – but it will take more than just Mono to acheive something like that.
you’re correct
if you look at mono’s goal as duplicating windows and being 100% compatible with it, that’s impossible…take a look at staroffice/openoffice. it’s an endless chase.
but if you want an easy-to-use programming environment that offers improving performance year after year and offers slight portability to windows…well, mono hits the spot
my take is that someone/some group has to advance a really compelling API/library for .NET that people will code to so that they won’t have to rely on the MS namespaces (which may be patented). like if GTK# really gets good and easy to use for the windows people, then we might see more code using it than Windows Forms
Can you make (fairly) standalone apps with mono? So someone can just download my free app for windows/linux, install and go. Without having to install all the mono stuff?
Yes. you can link statically only what you require which is called a embedded runtime.
yep that will be good for a start but eventually that won’t be good as it would be too much duplication.
i hope ximian would come around to having an easy-to-install runtime version separate from the dev stuff. sort of like having the .NET framework download separate from the .NET SDK, and the java JRE separate from the java JDK
Novell did a success story on that Mono deployment:
http://www.novell.com/success/volcker.html
Of course, David is on a crusade to attack anything Mono
or Gnome.
I find it interesting that he will always post on these
threads to attack either project, never to add anything
constructive.
My prediction: he sees Gnome as a threat to his desktop
of choice, and hence takes it upon himself to FUD anything
that would remotely help Gnome.
Miguel
Hello, noone,
Starting with Mono 1.1.3 we provide support for “bundles”
which are effectively applications that embed everything you
need from Mono to run without any dependencies.
For Mono 1.1.4 we will likely ship a “tuner” that will
let you shrink the download size significantly, the full
product to be ready on Mono 1.2.0
Maybe someone here can answer some questions regarding optimization flags and aot:
If I don’t specify the -O flag, will no optimization be done by the JIT?
Does -Oall acutally work (performance doesn’t seem better than specifying nothing at all for SciMark)?
Each optimization has (currently) to be specified like -OoptimizationA,optimizationB?
What’s then a good combination of the optimizations?
Is it actually a good idea to run mono –aot *.dll on the mono assemblies in /usr/local/lib/mono? [I think MS has ngen’ed their assemblies]
Thanks,
Stefan
First, this is a question that should really be asked on the mailing list. But I will answer it here.
1) Regarding the use of -O flags
Things that are not in the default -O set are not there for one of two reasons:
a) For most programs, they increase jit time more than they help thigns out. For example, bootstrapping mcs with -O=all takes more time than without the flag. This is because the ssa creation takes longer than the amount of time we save with the optimization. Generally, the optimizations help with cpu intensive programs. One of the things that would be cool to have is some profile guided optimizations
b) On running aot. In general, aot is a win. There are a few corner cases where AOT can not generate code that is as good as what the jit will (because the jit knows a few things at runtime that the aot can not). But, running aot on mcs bootstrap is a huge win.
One of the reasons that AOT is not enabled by default is that it does not create position independant code. That is, we have to relocate the code at runtime. Compare this to .so files which can be loaded at any address. Zoltan has checked in a patch to HEAD that enables this style of code on the amd64. It is going to be harder to do for the x86 because that does not have PC relative addressing.
Even without PIC code, AOT is probably a win. I might cook up a patch to AOT the entire install, so that we can test this out.
Once again, David shows his ignorance on all matters. Miguel posted the link referring to the city of Munich using ASP.NET on Mono and we have haven’t heard a word out of him yet.
And some more braindamage from David…
Herein lies the issue you can’t comprehend. Everybody developing for .Net on Windows will be using a lot of Windows extensions such as DirectX and Windows.Forms (it will never be good enough to be 100% usable, just like Wine) which will ultimately tie them to Microsoft .Net and Windows. This will get worse as time goes on to the point where porting to Mono will really be some effort (it already is at the moment). The Mono developers will then have to make some serious decisions about replicating the Windows technology extensions people will be using, or accepting that following Microsoft was pointless in the first place.
So in David’s bizarro world, everybody that develops for .NET is gonna use directX. That right there tells you that David is a basketcase. And of course David is wrong about Windows Forms too. Mono has a managed implementation of SWF on the way with 4 full time developers working on it as well as volunteers.
David, get it through your thick skull that nobody cares about Swing. Even in Java 5, Swing fonts look like dog crap. It’s over. Kaput. We all know how bitter you are, but try to grow up.
If the point of Mono is to provide a good c# (and clr) environment for Linux, then they will absolutely (and almost have) succeed.
I know people try to get out of this by saying something like this, but they can’t. The goal of Mono (or one of the major ones) is to try and provide .Net compatiblity – hence the re-working of Windows.Forms. It’s actually been a stated goal of Mono.
You’ve also got to consider market weight – people will demand MS .Net features in Mono if they are to use it. Mono will only be relevant to people in the .Net world if it implements everything in the same way as Microsoft’s .Net. People don’t get it – people will rely on not only Microsoft’s namespaces but the implementations on Windows they depend on.
Novell did a success story on that Mono deployment:
As with all press releases it doesn’t describe the scope or usage of Mono. It could still quite easily be a trial.
The acid test will come when they cannot recreate a lot of the functionality of Microsoft’s .Net in Mono. I wonder which way they’ll go.
I find it interesting that he will always post on these
threads to attack either project, never to add anything
constructive.
The constructive point is the one that I’ve made about .Net, the weight of Microsoft’s market share and how that will push the demand for these Windows specific features for Mono te remain relevant to people. If you want people to actually use Mono you have to consider that. If you don’t find that constructive then you won’t find anything constructive.
You also haven’t replied to peoples’ questions about this letter that seems to have mysteriously disappeared about royalty free licensing of of Microsoft’s IP and the questions raised on it. No, the FAQ doesn’t answer any of those questions.
Please feel free to add something constructive.
My prediction: he sees Gnome as a threat to his desktop
of choice, and hence takes it upon himself to FUD anything
that would remotely help Gnome.
That isn’t a prediction. I don’t see Gnome as a threat from an open source development point of view – but there comes a point when you look at what will actually be required technology-wise from a desktop where you have to accept that it just isn’t good enough. That’s just the point – Gnome isn’t any sort of a threat to anybody
.
You might call it FUD, but those who actually work in the computing world (very few around here) know that it isn’t. Anyway, the above hardly meets the definition of FUD.
Once again, David shows his ignorance on all matters. Miguel posted the link referring to the city of Munich using ASP.NET on Mono and we have haven’t heard a word out of him yet.
Which is a Mono press release, doesn’t go into any detail and is something we’ve had five years of. I see a pattern…..
So in David’s bizarro world, everybody that develops for .NET is gonna use directX.
They’re going to be using .Net with Windows extensions that they will rely on – do try and expand your mind. Anyone who doesn’t realise it is totally ignorant of the past twenty years of computing history.
Mono has a managed implementation of SWF on the way with 4 full time developers working on it as well as volunteers.
Funded by what exactly?
David, get it through your thick skull that nobody cares about Swing.
When did I say anything about Swing and when did I say Java was good enough at the client-end? There’s a big leap between that and assuming that .Net is the way to go, which Mono will never get a piece of because .Net is tied to Windows for the reasons I’ve outlined.
I would have a Java back-end (the only thing complete and good enough on the server-side for development on non-Windows platforms) with a Qt front-end (the only thing technologically good enough at the client-end for development on non-Windows platforms).
Easy.