Mono 2.6 Released, Supports LLVM Generation

[BlackStar]

I bet results also matters for other people. It seems you deny to what you were claiming before.

How so?

If only results matters to you, it should be in your interest to support faster toolkit which QT is and which is able to give you better results then Mono.

Qt implies C++, which I refuse to touch unless I am paid for it.

Since I work on graphics programming, I use xlib/OpenGL directly through C#. If the profiler shows a performance issue, I fix it. If I can't fix it through C#, I drop down to native code. Much more efficient and much less error prone than coding everything in C++.

I recently started experimenting with OpenCL, which provides yet another optimization avenue for code that needs it (highly parallel numeric calculations).

We all say no ro Mono apps and you'are the only one and few others maybe who say the opposite. It's the same with java apps. The vast majority of end users find them sluggish and slow, so here we don't have few people who try to impose personal opinions but a large percentage.

That's an opinion, not a fact. There is a sizable developer community relying on Mono to build applications used by a large number of users (again, Tomboy, Banshee, Gnome Do and the rest). *You* may find those applications slow and sluggish, but lots of people don't.

[smitty3268]

"Slow" without qualification is meaningless. Slow in what way? On what hardware? Compared to what?

Much like porn, I know it when I see it. Your qualifications are useful when trying to fix the problems, but don't mean my observations are useless. For the record, the main problems tend to be responsiveness, occasional slowdowns that occur which i assume happens when garbage collection is going on. Startup time and painting/redraw time can also struggle.

For example, Gnome Do launches and runs fast here (Linux-on-a-8GB-USB-stick), so I don't know why you consider this slow. Tomboy and Banshee are relatively slow to launch, but run fine afterwards - in fact, I can't detect a speed difference between Rythmbox and Banshee in typical operations (importing folders, browsing albums, playing back music).

Ok, you caught me, I don't actually use Gnome Do. Does it even do that much? I'm guessing all the hard indexing work is still done in C code, right?

VS2008 seems to run plenty fast even on older hardware (I used to run it on a Pentium 4 with 1GB RAM at my previous job) and yes it does rely on .Net for several parts (its visual editors for example). It's true that VS2010 is being delayed due to performance issues, but it's also true that the new WPF-based editor can handle this without breaking a sweat (warning, your browser may die trying to open this file). That's better than the C++ editor in VS2008 and VS2005, for example.

I use VS2008 at work as well, and while it runs OK I wouldn't call it snappy. More importantly, the .NET parts are all very small and not things that would really impact performance of the whole app. Regarding your example file, there are plenty of C++ editors that open that file much more efficiently than VS2010 does.

If your argument is that a well written .net app can outperform a poorly written C++ one, then that is pretty obvious. It just isn't the typical case you run into though.

In any case, the fact is that there are tons of desktop application written or relying on .Net and Java technologies, which discounts the notion that these technologies are too slow for the desktop.

If you are saying that computers today are fast enough that they can run these applications fast enough that people will complain but still run them, then ok. I agree.

If you're saying these applications are as fast as the C++ equivalents or that people are unable to feel the difference, then that's where i disagree.

Since when do games not need to remain responsive? If anything, games have much harder performance requirements than desktop applications: fall below 30fps and you are toast! Desktop apps, in comparison, run idle for most of the time.

You do, of course. My point is that these scripts are likely running in a background thread, or on the server somewhere in a way that is not going to impact the responsiveness of the client at all. Again, if the core of the game was written in C# that would be one thing. Scripts running on top of another application is another. I have no problem using managed code where it is useful, and scripting code on top of a highly optimized core seems like one of those. Web apps seem like another. Complicated desktop apps with complex UIs that need to remain responsive doesn't seem like a good one, at least not yet.

In another post, you said you thought that managed apps were improving, and I agree. Perhaps in 10 years this argument will seem like the transition from assembly to C, I think managed apps are just going to get more and more popular and will run better. I just don't think we're quite there yet.

As far as I know, they were using a custom, compiled scripting language called LSL. Their wiki seems to confirm this, but I don't know the details.

It's absolutely no surprise to me that a custom language written with a custom compiler loses to mono, a runtime that has had a great deal of work put into optimizing it. This kind of stuff is hard, and requires a lot of work to do well.

[kraftman]

How so?

It's simple. You said it's the result that matters (before you were claiming: "I have not used the others but from an end user experience, whenever I hear for a Desktop app that is written in C or C++, I run away."), so it seems it's the language that matters for you. While QT is able to give you the same result as Mono when comes to features of final application, while it also gives you better performance, so in the end it gives you better result. If results matters use QT.

Qt implies C++, which I refuse to touch unless I am paid for it.

Another example. It looks result doesn't matter, but just language.

*You* may find those applications slow and sluggish, but lots of people don't.

This is not a FACT, but only your opinion.

[BlackStar]

Finally, a rational and well-reasoned post! ( Not kidding. )

For the record, the main problems tend to be responsiveness, occasional slowdowns that occur which i assume happens when garbage collection is going on. Startup time and painting/redraw time can also struggle.

Startup time is a real issue, but it's not an intractable problem. (AOT compilation almost completely solves this).

Periodic slowdown can certainly be caused by the GC, but frankly this is unlikely to be detectable in non-realtime applications. The GC runs on a seperate thread and typically finishes in less than 10ms - unless of course you are abusing memory really really bad, by creating thousands of temporary objects per second. (This kind of abuse would land you into trouble even on C++, so lets just ignore it.)

To give a sense of perspective on this 10ms number:
1. 10ms is the maximum recommended latency for audio recording (meaning that the human brain can automatically compensate for a 10ms delay between playing an instrument and hearing the sound from the speakers)
2. 10ms is 20 times better than the average response time to visual stimuli (this number is based on an experiment I participated in). In other words, your brain needs about 200ms to decide whether to click on a button that just appeared on the GUI in front of you (not counting the time you need to move the cursor and click). This paper suggest that latencies up to 195ms are virtually undetectable on mouse interaction - this means that a typical GC cycle will go completely unnoticed on normal desktop apps.
3. 10ms is the difference between smooth framerate and jitter on a game. Typical games run at 60fps, which translates to 16.66ms per frame. If a GC cycle takes 10ms, you are pretty much forced to miss a frame. This is why XNA games must be very very careful to not allocate memory after loading a level.

Without knowing anything about the nature of the application, I would attribute periodic slowdowns either to disk activity or to the JIT visiting some part of the application you never touched before.

An anecdote some people might find interesting: last year, I was working on a VR application that would act as the frontend for a brain-computer interface. VR is even harder than typical games, because dropped frames cause real, physical effects on the subjects (nausea, disorientation). The simulation had to maintain a fluid framerate of 120fps (60fps per eye), while decoding incoming data in realtime.

Language of implementation? C#. Technology? OpenGL, running on Linux, Windows or Mac OS X (single binary for all platforms).

GC performance was a very real and pressing concern from the beginning of the project (8.33ms per frame means you really cannot afford a GC, especially with the CPU running at 100%). However, the solution proved to be simple: allocate all necessary data up front at load time and use a memory pool for short-lived objects during runtime (e.g. for the heads-up text display and decode buffers).

The other concern was numerical performance, which is maybe the weakest part of .Net (Mono can perform much better here using SIMD intrinsics). There was a real chance that we'd have to drop down to native code for this part, but in the end the concern proved empty. A typical dual core CPU could decode the data, run the simulation with power to spare.

Would this project run faster on C++? Yes, probably yes, but you really wouldn't know the difference (edit: since we lock at 120fps). However, had we gone with C++ we wouldn't have been able to design and implement the project within the 9 month deadline.

This is why I don't buy into the unqualified ".Net is too slow" argument. I'm well aware that .Net may be too slow for some things - but it's capable to power a surprising amount of applications without an appreciable performance drop.

You do, of course. My point is that these scripts are likely running in a background thread, or on the server somewhere in a way that is not going to impact the responsiveness of the client at all. Again, if the core of the game was written in C# that would be one thing. Scripts running on top of another application is another. Web apps seem like another. Complicated desktop apps with complex UIs that need to remain responsive doesn't seem like a good one, at least not yet.

XNA games are pure C# and this doesn't seem to cause any real problems. Games also tend to be much more resource intensive than than apps with complex UIs, at least as far as memory and CPU throughput is concerned. Desktop apps tend to be more disk intensive, but disk throughput is hardly impacted by .Net. In fact games are placed at a much larger disadvantage from the use of .Net and yet they don't seem to fare all that badly.

[BlackStar]

It's simple. You said it's the result that matters (before you were claiming: "I have not used the others but from an end user experience, whenever I hear for a Desktop app that is written in C or C++, I run away.")

I think you need to develop your sense of humor.

This is not a FACT, but only your opinion.

Of course it's my opinion, that's the whole point. The poster I quoted was trying to pass this opinion as a fact (the inverse of this opinion, to be pedantic).

[Apopas]

That's an opinion, not a fact. There is a sizable developer community relying on Mono to build applications used by a large number of users (again, Tomboy, Banshee, Gnome Do and the rest). *You* may find those applications slow and sluggish, but lots of people don't.

Exactly! A percentage find them sluggish while the rest find them neat. The problem is that if we have to deal with percentages that seems ther eis indeed a problem. For example as I said before the vast majority of people find java sluggish. Maybe it's not the vast majority but a rather big percentage, something that does not happen with C or assembly applications and that's a fact, not a personal opinion. I don't need to count that amount of grains of sand that a beach has to be able to say they are millions.
As a greek adage says: Χωριό που φαίνεται κολαούζο δεν θέλει, μπλακσταρ

And as Kraftman noticed above, your problem is finally with the language rather than the result. If the result was your main concern, well we wouldn't need to hav this discussion at all.

[BlackStar]

And as Kraftman noticed above, your problem is finally with the language rather than the result. If the result was your main concern, well we wouldn't need to hav this discussion at all.

Actually, if you would just get over your misconception that the language of choice is *the* deciding factor in application performance we wouldn't need to have this discussion at all.

For the record, I pick a programming language as a means to an end. Languages are tools and, for better or worse, C++ is a surprisingly inefficient tool in a lot of regards: programming efficiency, portability, stability. My experience is that falling back to plain C is much more efficient than trying to reason with C++. YMMV.

[Apopas]

Actually, if you would just get over your misconception that the language of choice is *the* deciding factor in application performance we wouldn't need to have this discussion at all.

I've used thousands of apps, almost always I find java apps, mono apps and python apps to perfrom worse in comparison with the others. I can see it even if I don't know with what laguage a specific app is written. That can not be just by bad luck. I don't believe to luck at all...

[XorEaxEax]

GC performance was a very real and pressing concern from the beginning of the project (8.33ms per frame means you really cannot afford a GC, especially with the CPU running at 100%). However, the solution proved to be simple: allocate all necessary data up front at load time and use a memory pool for short-lived objects during runtime (e.g. for the heads-up text display and decode buffers).

So they needed to code past the performance problem of garbage collection by reusing data structs in order not to trigger the gc. Not really in line with your argumentation that the garbage collecting doesn't affect performance much.

The other concern was numerical performance, which is maybe the weakest part of .Net (Mono can perform much better here using SIMD intrinsics). There was a real chance that we'd have to drop down to native code for this part, but in the end the concern proved empty. A typical dual core CPU could decode the data, run the simulation with power to spare.

Yeah I heard that it generates crappy floating point math, whats up with that?

Would this project run faster on C++? Yes, probably yes, but you really wouldn't know the difference (edit: since we lock at 120fps). However, had we gone with C++ we wouldn't have been able to design and implement the project within the 9 month deadline.

This makes perfect sense, the speed impact of managed code and the subsequent code-around was outweighed by the faster development time and since there was a specific performance target, as long as that is met it's performing well enough.

However in many cases there is no thing as a specific performance target. Instead it's faster performance = more productive.

XNA games are pure C# and this doesn't seem to cause any real problems. Games also tend to be much more resource intensive than than apps with complex UIs, at least as far as memory and CPU throughput is concerned. Desktop apps tend to be more disk intensive, but disk throughput is hardly impacted by .Net. In fact games are placed at a much larger disadvantage from the use of .Net and yet they don't seem to fare all that badly.

Well, when it comes to XNA games, hardware accelerated graphics and sound makes it so that C# pretty much only handles the actual game logic.

Also as for XNA and phones running managed code, this is a tradeoff between performance and security. They need to have the code running in a VM so that an application can't do nasty things. It's not a selling point for managed code performance, it is however a selling point for managed code when it comes to security.

[BlackStar]

So they needed to code past the performance problem of garbage collection by reusing data structs in order not to trigger the gc. Not really in line with your argumentation that the garbage collecting doesn't affect performance much.

A C++ application that allocated temporary objects on the heap per frame would face similar performance issues. In fact, every single modern game in existence worth its salt utilizes memory pools of some short, so I don't see why you think this is a big deal.

The fact that this was the only significant optimization necessary to get acceptable CPU performance is a testament to the viability of .Net (or the speed of modern CPUs, if you wish to be jaded - which pretty much boils down to the same thing). In fact, optimizing shaders and assets played a much bigger role in performance compared to optimizations on the CPU side.

Yeah I heard that it generates crappy floating point math, whats up with that?

Its floating-point code is about on par with C++, which isn't terribly good by default (stack-based FP is rather inefficient). However, the big disadvantage is actually reaching the floating-point calculations in .Net: lack of const references and very conservative inlining means that the runtime has to copy structures more than would be necessary in C++ - and this has a measurable impact on performance.

Mono.SIMD attempts to fix this by exposing SSE instructions to Mono applications in a cross-platform manner. As far as I know, this library is a first for managed languages and initial tests indicate a significant increase in performance over raw C# code. runtimes. I plan to test this avenue more in the future but right now I'm focusing on OpenCL.

What I like is that Mono seems to be adding a significant amount of game-related APIs (tasklets/continuations are the latest addition). I think it will be interesting to see how this will turn out. (Yes, I know, politics, Mono is the devil etc. I'm interested in the technical side here).

Well, when it comes to XNA games, hardware accelerated graphics and sound makes it so that C# pretty much only handles the actual game logic.

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.

While I don't think this approach can work for a cutting-edge AAA title right now, I expect this will actually become possible once with hardware accelerated (OpenCL) physics make their appearance (physics are the single biggest CPU hog in a modern game).