Mono 2.6 Released, Supports LLVM Generation

[Apopas]

Which people? What app? Who knows! Everyone is saying that Mono/Java/blah sucks, so it must be true. Sun, Microsoft, Novell, Google, the Python Foundation, the Ruby Foundation and everyone else who has spend decades researching and implementing runtimes, all of them have simply wasted their money on things that are not suitable for the real world.

Either do some research and provide evidence for your claims or stop sprouting this nonsense.

Isn't hard to find people who hate to use java applications on their desktops. Actually the difficult thing is the opposite. From an end user experience, java apps like vazu, frostwire etc feel huge and exceptionally slow. That's a reason I switched JDownloader for Tucan, despite that the first is a much more complete application than the second one and I'm not alone to that, I remember in ubuntu-gr forums the guys keep asking for a good download manager that is not java.
Also, after 9 years of using Gnome I swtiched to KDE nd with it and almost all of my apps. Deluge for Ktorrent, Pidgin for Kopete, Evolution for Kmail etc. They run faster than their gtk+ counterparts, so I assume that Gnome with Mono is gonna become even slower. All these from an end user perspective.

[BlackStar]

Don't take those results too seriously please, because it seems it's not so easy to check applications memory usage on Linux (it's probably much more efficient then some tools report).

I'm not sure what's your point here. but will it be correct if I say: utorrent loses on Linux (presumably due to native Win Api)? :>

Utorrent doesn't even try to be cross-platform, so it loses on Linux by definition.

Isn't that you who fell to give an example of fast/not resource hungry Mono or Java application? Basing on some posts Paint.net is out of a game.

I've given something more substantial than a single application: a link to a honest, technical analysis of the relative efficiencies and inefficiencies of .Net compared to a native C++ application, performed by one of the leading experts in the field (if not *the* leading expert). If you can't appreciate that, then any amount of examples simply won't matter - you'll conveniently ignore them (like Paint.Net).

Besides, I've yet to see one shred of technical evidence to support the ridiculous claim that .Net and Java is unsuitable for the desktop. (This claim sounds pretty similar to what assembly programmers used to say a couple of decades ago, fancy that!) Can you find something more substantial than mere anecdotes? The ball's in your court now.

I'm off to bed, g'night fellas!

[XorEaxEax]

There is no such thing as a free lunch.

Exactly. But you are arguing that there is, you claim that not only does managed code do all these extra things for you, but that it does it and still is faster than native code. You give flawed examples (like Paint.net which relies on gdi+) and downright false (like transmission which is written in c). All the while ignoring the performance cost that comes with automated garbage collection and heap defragmentation (moving memory blocks and updating pointers to them is not cheap). I'm not arguing against managed code, I like it for alot of projects. I'm arguing against your claims that it performs better than native code with managed memory management, which isn't true.

Of course you can implement (or try to implement) a conservative garbage collector in e.g. C++, but in doing so you'll simply recreate a less efficient, more buggy version of the .Net GC. Sometimes it makes sense to do exactly that (Mozilla did it, for example). In most cases, you'd be better of using a runtime that provides this out of the box: Mono, Python, Java, Ocaml, whatever, take your pick!

How is this relevant to the discussion? We were talking about explicit memory management versus automated.

Ah, here's the thing: you can compile to native code on the target system, not on your development system. You can do this during installation, on first startup or whenever - it's your choice.

You can use a static compiler and do the exact same thing. Use "-march=native" to have the code generation make use of the target machine capabilities.

[kraftman]

I've given something more substantial than a single application: a link to a honest, technical analysis of the relative efficiencies and inefficiencies of .Net compared to a native C++ application, performed by one of the leading experts in the field (if not *the* leading expert). If you can't appreciate that, then any amount of examples simply won't matter - you'll conveniently ignore them (like Paint.Net).

This is the problem, there aren't efficient Mono apps! Only some MS analysis

[BlackStar]

Exactly. But you are arguing that there is, you claim that not only does managed code do all these extra things for you, but that it does it and still is faster than native code. You give flawed examples (like Paint.net which relies on gdi+) and downright false (like transmission which is written in c). All the while ignoring the performance cost that comes with automated garbage collection and heap defragmentation (moving memory blocks and updating pointers to them is not cheap). I'm not arguing against managed code, I like it for alot of projects. I'm arguing against your claims that it performs better than native code with managed memory management, which isn't true.

Indeed, I was wrong about Transmission and for that I apologize.

This doesn't change the fact that GC can be more efficient than manual memory management in the short run (faster allocations) and in the long run (reduced fragmentation, reduced chance for memory leaks). On average it's safe to assume that the default .Net GC will perform better than the default allocators of GCC or MSVC.

You can use a static compiler and do the exact same thing. Use "-march=native" to have the code generation make use of the target machine capabilities.

Sigh, which part of the "compile the bytecode to native on the target machine" doesn't make sense? In your example, the user must recompile from source, a process which may take hours for non-trivial C++ programs. In the AOT case, you take the compiled bytecode executable (which is platform agnostic but needs a JIT to run) and recompile it directly on the target machine (you "pre-JIT" it if you will, a process that takes seconds). The result is a native binary that loads as fast as a, well, a native binary.

Really off to bed now.

[BlackStar]

I've given something more substantial than a single application: a link to a honest, technical analysis of the relative efficiencies and inefficiencies of .Net compared to a native C++ application, performed by one of the leading experts in the field (if not *the* leading expert). If you can't appreciate that, then any amount of examples simply won't matter - you'll conveniently ignore them (like Paint.Net).

This is the problem, there aren't efficient Mono apps! Only some MS analysis

Oh dear...

[XorEaxEax]

Indeed, I was wrong about Transmission and for that I apologize.

This doesn't change the fact that GC can be more efficient than manual memory management in the short run (faster allocations) and in the long run (reduced fragmentation, reduced chance for memory leaks). On average it's safe to assume that the default .Net GC will perform better than the default allocators of GCC or MSVC.

The short run? I can write a memory pool allocator for native code that is tailored to my specific program and thus much more efficient than a generic garbage collector. And I do not have to suffer the overhead accompanied by automatic memory reclaiming. As for memory fragmentation, the various OS'es does a great job at keeping memory fragmentation to a minimum. The need for compaction (memory defragmentation) in VM's is due to them maintaining their own heap, and in order to keep that heap as small as possible (since the rest of the system will be unable to access the VM's heap) it will move blocks of data and update references to this data accordingly which is not cheap at all. Add to this that the garbage collecting logic itself is quite complex (traversing objects and checking references to other objects and identifying which are pinned etc...) and you have quite a bit of overhead.

Automatic garbage collecting has great benefits in safety and ease of programming, but it comes with a cost in performance. If the benefits outweigh the costs is up to the programmer (and ultimately the recipient of the program if they are not one and the same) to decide.

Sigh, which part of the "compile the bytecode to native on the target machine" doesn't make sense? In your example, the user must recompile from source, a process which may take hours for non-trivial C++ programs.

The amount of time heavily depends on the level of optimization, JIT compilers are do not use heavy optimization passes such as that of static compilers at high optimization levels, and are thus faster. But you can use lower optimization levels on static compilers aswell. Granted, compiling bytecode is faster than compiling from source.

[BlackStar]

The short run? I can write a memory pool allocator for native code that is tailored to my specific program and thus much more efficient than a generic garbage collector. And I do not have to suffer the overhead accompanied by automatic memory reclaiming.

You can use a memory pool in .Net too and avoid GC overhead. What's your point?

As for memory fragmentation, the various OS'es does a great job at keeping memory fragmentation to a minimum. The need for compaction (memory defragmentation) in VM's is due to them maintaining their own heap, and in order to keep that heap as small as possible (since the rest of the system will be unable to access the VM's heap) it will move blocks of data and update references to this data accordingly which is not cheap at all. Add to this that the garbage collecting logic itself is quite complex (traversing objects and checking references to other objects and identifying which are pinned etc...) and you have quite a bit of overhead.

You are downplaying the issue of memory fragmentation. This is a real problem in non-trivial applications and the potential solutions are far from simple: use multiple heaps, use custom memory allocators, use memory pools. Each solution has its issues (non-portable, dangerous and non-generic, respectively) which become at least an order of magnitude more complex once you add a 3rd party library that isn't aware of your memory management strategy.

All this pain for something that is a non-issue in managed environments.

Anyway, I'm not making a blanket statement that .Net memory management is faster than anything you could do in native code, that's ridiculous. I'm saying that it has real performance advantages out of the box (again, faster allocations compared to default CRT allocators, less fragmentation). Obviously, this doesn't mean that you won't have to optimize any given .Net app to improve GC performance, only that it's less likely that you'll havo to do that. For the vast majority of applications, the defaults are good enough (this holds for C++, too).

[Hoodlum]

@Hoodlum: ok, you have convinced me, Java, .Net and the rest of the managed runtimes are too slow for most (but not all) desktop applications. No really, your anecdotes are very convincing.

I said .net and java, you said "managed runtimes" good luck trying to change the arguement to suit you though.
I've provided a list of programs where the that is the case, you have provided a list of....oh yes, no examples.

Oh wait, you haven't even bothered to give an anecdote. All you have said is that people are complaining that Mono and Java is too slow and that you have never seen a managed app that is fast relative to a C++ app.

I'm sorry I don't subscribe to your "disprove god" style of arguement but i'll indulge you anyway:

I can go one better than your "anecdotes" - facts. I have provided factual examples, something you have time and again failed to do. Transmission is a nice example of yours, another one that supports my arguement against you (lets compare it to monsoon should we, the mono equivilent?). Paint.net for the reasons other people have stated (relying on GDI+ to be performant) is a good example of why mono/.net are not good for the majority of cases that require performance (and C/C++ are), so thank you for supporting my arguement.

As reasoning and logic seemed to have had no effect on you I went on to explain to you the basic thought process behind why people find them slow (hint: because they are) which you failed to grasp and thus continued to deny or avoid by changing the subject every time you had no ability to counter the arguement - Raving about how utorrent uses less memory on ktorrent on a non native platform.

I've given something more substantial than a single application: a link to a honest, technical analysis of the relative efficiencies and inefficiencies of .Net compared to a native C++ application, performed by one of the leading experts in the field (if not *the* leading expert)

.
You've been unable to provide a single, valid example and provided a "technical analysis" from an employee of the company who created the product on their company blog? Brilliant.

Using that level of scrutiny I should believe all the clean coal research that shows massively lower pollution (hint: clean coal is a farce). I'm not denying that the man knows his stuff but starting out with an "analysis" that is from inception intended to show C# in a positive light is a logical fallacy. I would believe him no more (or less) than I would believe an analysis of QT by a nokia employee.

If you want a fair analysis you start with a neutral party. Remember the tobacco research that showed that smoking was good for your health? Yeah funded by tobacco companies....lets guess where his wages come from shall we. I do not know him as a person so I cannot judge how impartial he really is and I doubt you do either.
I cannot believe I have to explain something this simple to you.

[BlackStar]

I can go one better than your "anecdotes" - facts. I have provided factual examples, something you have time and again failed to do. Transmission is a nice example of yours, another one that supports my arguement against you (lets compare it to monsoon should we, the mono equivilent?). Paint.net for the reasons other people have stated (relying on GDI+ to be performant) is a good example of why mono/.net are not good for the majority of cases that require performance (and C/C++ are), so thank you for supporting my arguement.

Hint: the plural of anecdotes is not data.

Do you know which language is used for Paint.Net filters? That's right, it's C#. Check here or, for a concrete example, here.

Paint.Net has been moving away from GDI+ due to performance issues (source). Even if it didn't use GDI+, it would have used plain GDI, WPF or maybe D3D/OpenGL - there's no other way to render to screen on win32. This argument that Paint.Net is using GDI+ so it's not a valid .Net app doesn't make any sense - but then again neither does anything other you have written.

You might as well argue that the .Net runtime is written in C++ so it doesn't count.

You've been unable to provide a single, valid example and provided a "technical analysis" from an employee of the company who created the product on their company blog? Brilliant.

Using that level of scrutiny I should believe all the clean coal research that shows massively lower pollution (hint: clean coal is a farce). I'm not denying that the man knows his stuff but starting out with an "analysis" that is from inception intended to show C# in a positive light is a logical fallacy. I would believe him no more (or less) than I would believe an analysis of QT by a nokia employee.

"From the inception intended to show C# in a positive light?" My, are you blinded by hatred. It is obvious that you didn't even make the effort to read the technical analysis - the irony here is that it concludes that C++ is ultimately more efficient than C# (and explains exactly how, where and why).

I ask you directly, can *you* provide a valid technical examination of C++ versus C#? Unless you do at least that much, there's no point in continuing this discussion.

Hint: reiterating that .Net is slow without proof won't make your point valid.