Mono 2.6 Released, Supports LLVM Generation

[XorEaxEax]

A C++ application that allocated temporary objects on the heap per frame would face similar performance issues.

Yes and no, manual memory management means you have full control of when you allocate/free memory, so you would be able to set a threshold of how many objects you can allocate/deallocate during a frame and thus be able to keep the overall memory usage much lower. That said, yes reusing objects rather than creating new instances is always a good practice as far as performance is concerned. Also (and often with games) as I understand it this application was running pretty exclusively and thus has all the hardware's resources at it's disposal so pre-allocating all necessary memory has no negative impact.

In fact, optimizing shaders and assets played a much bigger role in performance compared to optimizations on the CPU side.

Yes, but that's has nothing to do with native versus managed code performance. I used a nice 3d modeler called Wings3d a while back which was written in interpreted Erlang. The reason it ran well was due to OpenGL 3d acceleration, which was very evident whenever it had to perform heavy calculations rather than just sending display lists.

(Yes, I know, politics, Mono is the devil etc. I'm interested in the technical side here).

Well I do not subscribe to that line of thought. Even though I have no illusions that Microsoft is helping Mono for any other reason than that to beat Java they need cross-platform support.

This holds for all games, not only XNA ones. Modern games seem to be something like 80% scripts and 20% engine. XNA just takes the next logical step and replaces the last 20% with managed code.

Yes, which makes games a pretty poor choice for comparison. The Language Shootout makes Mono look pretty bad, but then again Mono is still under heavy development so I think that it will improve a lot given time.

[BlackStar]

Yes and no, manual memory management means you have full control of when you allocate/free memory, so you would be able to set a threshold of how many objects you can allocate/deallocate during a frame and thus be able to keep the overall memory usage much lower.

I'm not sure what you mean here. It is true that you can set a threshold with manual memory management relatively easily (allocating/deallocating up to n objects does not have a significant performance impact), but the threshold doesn't affect overall memory usage. Memory usage is dictated by the needs of the application - if you have 1GB of textures you have 1GB of textures no matter if you have a GC or not. What the threshold *does* affect is memory usage patterns, i.e. how you allocate your n objects per frame: if they fit under the threshold you are set; if they don't you need to optimize.

It is much more difficult to set such a threshold for GC-enabled runtimes, because the implementation of the GC impacts this threshold directly. It is possible (there are optimization guides for the .Net GC that explain exactly how to do this, mainly by keeping the object graph simple and limiting the GC to gen-0 collections), but it's generally easier to optimize for allocating memory beforehand + memory pools.

I should note that these optimizations are pretty much specific to games, which need to maintain low and predictable latency. Other applications have looser latency requirements (if the disk needs 500ms to serve the file you just clicked, a GC cycle would have absolutely no impact on performance).

Yes, but that's has nothing to do with native versus managed code performance. I used a nice 3d modeler called Wings3d a while back which was written in interpreted Erlang. The reason it ran well was due to OpenGL 3d acceleration, which was very evident whenever it had to perform heavy calculations rather than just sending display lists.

Wings3d is written in what? Cool, I thought Erlang was mainly meant for highly scalable server-side applications rather than desktop apps. No idea it could do 3d (but then again why not?)

Yes, which makes games a pretty poor choice for comparison.

Why? If anything, games would reveal a performance regression much sooner than a complex UI would. Even a 1ms regression will have a measurable impact on a game, whereas the same regression will be all but lost in the noise in a complex UI.

[ciplogic]

Yes, which makes games a pretty poor choice for comparison. The Language Shootout makes Mono look pretty bad, but then again Mono is still under heavy development so I think that it will improve a lot given time.

I'm a .NET developer and I use Linux at home as my primary desktop. As far as I know and understand the .NET world the issues are three categories that person found Mono slow:
- JIT time at startup: every function before being run it have to be made in an executable form. A complex application like the one I wrote, by just doing preJIT (named Ahead of time) by ngen, will reduce the startup time by a half and will put in the same category with C++. Anyway, after this JIT is done, most operations right away run smooth, no other big JIT pauses.
- GC pauses times: they are significant and interruptions of current algorithm will make some persons to see those pauses. The compacting GC algorithm that will be made sometimes in the subsequent releases, will make things hopefully better because pauses will be done mostly in the last generation
- JIT code quality. For a lot of applications the best performance you can get just by assembly. The close second is Fortran, then C++, then JIT based languages (like Java and .NET). There can be found a case when assembly code gets better than Fortran code, so you will have to write a small part in assembly. The real solution for those cases is just to write in the proper language that met your requirements. Today, excluding cases when things are just not enough simple (writing drivers as you don't have access to interrupts, and you don't want to start a JIT just for a very small utility as "cat" bash application). But in rest of cases that JITs give just enough performance.
Mono mostly in Language shootout enters in two classes of performace problems: GC pause times and JIT code quality. The 64 bit version is better than Freepascal today (in intensive loop codes) but memory seems to slow it down.
Wanna get the ultimate performance startup? Just ask your distribution to do AOT for your binaries: mono -O=all --aot --full-aot program.exe (source: http://www.mono-project.com/Mono:Runtime ) or DIY. Also wait until CompactGC will be a part of Mono to have small pauses. Having those two operations implemented I think that Mono will give you just enough for desktop performance.

[BlackStar]

The real solution for those cases is jut to write in the proper language that met your requirements.

So you agree that Mono is too slow.

Today, excluding cases when things are just not enough simple (writing drivers as you don't have access to interrupts, and you don't want to start a JIT just for a very small utility as "cat" bash application). But in rest of cases that JIT gets just enough performance.

Ha, Mono is useless, I knew it! It cannot even create simple applications like cat without being too slow and sluggish. Imagine then what would happen with complex applications!

Mono mostly in Language shootout enters in two classes of performace problems: GC pause times and JIT code quality. The 64 bit version is better than Freepascal today (in intensive loop codes) but memory seems to slow it down.

In other words, Mono performs worse than assembly, which means it is too slow. Like Java.

Wanna get the ultimate performance startup? Just ask your distribution to do AOT for your binaries: mono -O=all --aot --full-aot program.exe (source: http://www.mono-project.com/Mono:Runtime ) or DIY. Also wait until CompactGC will be a part of Mono to have small pauses. Having those two operations implemented I think that Mono will give you just enough for desktop performance.

As you said, Mono is too slow without doing a *lot* of work (like passing a couple of commandline parameters). Not to mention that AOT creates native code, so you might as well write in C++ and Qt from the beginning. (Qt of course, because GTK is slow and sucks and I wish it would die already. Die, GTK, die! Also Mono, Gnome, GTK, Miguel and evil Micro$_$haft borgs - die!)



(Only kidding of course, I'm just trying to understand how the other side builds their arguments. I agree with everything you wrote, btw.)

[kraftman]

(Qt of course, because GTK is slow and sucks and I wish it would die already. Die, GTK, die! Also Mono, Gnome, GTK, Miguel and evil Micro$_$haft borgs - die!)

Saying (no matter if you're kidding) that someone should die isn't funny.

(Only kidding of course, I'm just trying to understand how the other side builds their arguments. I agree with everything you wrote, btw.)

Simple:

Wanna get the ultimate performance startup? Just ask your distribution to do AOT for your binaries: mono -O=all --aot --full-aot program.exe (source: http://www.mono-project.com/Mono:Runtime ) or DIY. Also wait until CompactGC will be a part of Mono to have small pauses. Having those two operations implemented I think that Mono will give you just enough for desktop performance.

Then performance should be enough for desktops, but it depends what enough means for people.

Ha, Mono is useless, I knew it! It cannot even create simple applications like cat without being too slow and sluggish. Imagine then what would happen with complex applications!

Give a real world example of simple Mono application which isn't sluggish now. Tomboy maybe? It's hard to find anything more simple, but Tomboy is sluggish...

[ciplogic]

Then performance should be enough for desktops, but it depends what enough means for people.
Give a real world example of simple Mono application which isn't sluggish now. Tomboy maybe? It's hard to find anything more simple, but Tomboy is sluggish...

One application that do not feel sluggish is Banshee. In fact was much faster to index large libraries than Rythmbox on my machine. Also, Eclipse is faster for large projects than KDevelop or QtCreator. Should we conclude that Java is better than C/C++? MonoDevelop for C# only projects works enough nice. I did make programs with an Atom based CPU and works like a bliss.
A Java/Mono application work like this: an extra application (named the virtual machine) reads the code that describe an application and it's dependencies. After this based on the code-flow described, it creates an executable form of that functions. This is the JIT time talked previously. In real world applications in most cases the hit of performance is around 1/2 if the program do not implement the really same algorithm. If is implemented the same algorithm, the same data-structures, the performance mostly goes like: 10-20% slower for integer's code performance and around 50% slower for floating point code. This may mean a lot for some, and nothing for others.

The single side-effect that make you to feel sometimes a Mono application slower is the "unexpected" garbage collection.
Also, because Mono is not only a JIT, but is also a runtime, many developers prefer high level classes to make clean the design of application, which in most cases give another scalability profile, and in most cases consumes more memory. What means scalability profile? I use (almost) always in my code SortedDictionary class that index the search operations in log(n) time, meaning that most operations do take a quantity of time proportional with digit count of n (for operations like: add, search, remove). This will mean that will work different from other programs that use List classes which searching is O(1) if you know the index (meaning constant time), insertion is O(1), but a random search is O(n) meaning to find all items that match a criteria will take as much time as the items are in list. By this I want to make clear that depending on developers' decisions, your application may run fast or slow, is not just a fault of Mono, Python, you name it.
Also, talking about real life: Mono most of time do not consume as much CPU as use the other Gtk/Gnome code like: resizing the layout, the fonts layout, internationalization, font image. In fact a Mono/C# program that will open a file using Windows.Forms custom written (using the TextBox control) will start faster than GEdit. The reason is that this Mono should load this: Mono's JIT which launch Glib, your application assembly, Windows.Forms, System.Drawing, Cairo and Gtk. The layout is more simplistic in Windows.Forms than in Gtk, so will take less CPU, the font drawing the same (as is based on Cairo). GEdit loads like this: Glib (standard library), Gtk, Gnome plugin support, reads settings from GConf, which uses libxml2 to parse the config, the same happen that Gedit will load the plugins' configs again other xmls. At the end there is a mapping table (for making syntax highliting), help libraries, a lot other. Please make a small program and show to me that you get slower times than GEdit. Why GEdit is not rewritten in C#/Mono? The answer is just this: excluding the fanboys that purpose that, there is no real benefit in both directions: GEdit is mature, just works. Why reinvent it?

[kraftman]

Please make a small program and show to me that you get slower times than GEdit. Why GEdit is not rewritten in C#/Mono? The answer is just this: excluding the fanboys that purpose that, there is no real benefit in both directions: GEdit is mature, just works. Why reinvent it?

I'm not actually talking about smaller times (some not MS/Novel benchmark would be better in my opinion then completely different program). GEdit consumes about five times less memory then Tomboy and starts faster, so it wouldn't be sane to rewrite in in C#. When I say Mono apps are slow I mean start time and sluggishness (maybe depend on personal feeling) in some cases. It seems there's also big memory usage. You mentioned Rhythmbox, but this application is a great example how to make something sluggish, so I'm not amazed Banshee was faster in the case you wrote.

[BlackStar]

@Kraftman, what in the nine worlds does gedit have to do with tomboy? They are positively, abso-effing-lutely different applications with completely different functionality. Following your logic, Tomboy consumes 10x less memory than Firefox so it would be sane to rewrite Firefox in C#.

Ouch.

@ciplogic: there's absolutely no point in trying to argue with those people(*). No matter what you say, they will ignore it and repeat their mantra: "[x] feels to [y] for me, I hate it. Everyone says so."

Give examples of performant Mono applications? They'll give insane excuses and ignore them.

• Banshee may be fast, but Rythmbox is so slow that Banshee doesn't count.
• Paint.Net may be fast, but it uses System.Drawing so it doesn't count either.
• Gnome Do may be fast, but it's too simple and, besides, it uses C (no, it doesn't use C and no, it's not simple. Check its source.)

Notice a pattern emerging?

Also don't try to link to any technical information, they'll just ignore it as Micro$_$haft marketing or Mono advertisements. Rational thought doesn't even enter here. Why the hell would Second Life's community wiki advertize Mono? No idea, but it's talking about Mono so there must be something evil about it. Why would a blog post that (a) compares C++ and C# performance and (b) shows C++ to have superior performance, consist of C# marketing? Hey, it's written by a M$$$ employee, so of course it's C# marketing - no matter what the conclusion is.

It's like trying to reason with a brick wall. Only brick walls tend to have some sort of logic in them.

(*) No, I'm not talking about the people who argued against C# with reason, evidence and good arguments (you know who you are). Feel offended? Good. Try following their example next time.

[kraftman]

@Kraftman, what in the nine worlds does gedit have to do with tomboy? They are positively, abso-effing-lutely different applications with completely different functionality. Following your logic, Tomboy consumes 10x less memory than Firefox so it would be sane to rewrite Firefox in C#.

This is the point - Tomboy is just SIMPLE notes application and it consumes 5x (or sometimes 4x) more memory then GEdit which isn't so simple text editor and the SAME amount of memory as Firefox, so what you said is bull . Maybe a picture will be more readable to you:

http://i48.tinypic.com/2rrtmwx.png

Following my logic it would be sane to rewrite Tomboy in what GEdit is written, so now I see how your logic works

[BlackStar]

This is the point - Tomboy is just SIMPLE notes application and it consumes 5x (or sometimes 4x) more memory then GEdit which isn't so simple text editor and the SAME amount of memory as Firefox, so what you said is bull . Maybe a picture will be more readable to you:

http://i48.tinypic.com/2rrtmwx.png

Following my logic it would be sane to rewrite Tomboy in what GEdit is written, so now I see how your logic works

How about a neutral source on Firefox's memory usage? About 10 times higher than Tomboy.

Gedit is a platform-specific, syntax highlighting text-editor. Tomboy is a cross-platform note-taking application with text formatting, hyperlinks and online sync. Their functionality is so dissimilar that comparing their memory usage is simply not useful.