Mono 2.6 Released, Supports LLVM Generation

[Hoodlum]

Every *application* that runs on my phone is written in freaking *Java*. The same holds for most phones in the world, *except* iPhone which uses Objective-C or Mono instead.

I'm not talking about the OS, I'm talking about mobile applications. What is so difficult to understand here? You keep harping that Java is too slow for mobile applications, when the vast majority of mobile applications are written in Java.

I'm not concerned with little applications to which you refer, the stack is not. That is my point. If either language were the holy grail of cross platform performance as you are claiming it would be optimal to use a stack based on them, there is no such thing, they are too slow for this. They may be fine for acceptable performance on small top level applications but as I said, nothing significant, nothing that requires performance.

UPX claims an average compression level ratio of 0.307:1 (source). Assuming this holds for utorrent, the uncompressed executable would be ~919KB

It is slightly higher 936kb -ish iirc but this was a while ago. I'm glad you now understand what i said.

- still smaller than the *bootstrap* installer of ktorrent, which doesn't even contain Qt.

Never said it wasn't, just that it is as fast as utorrent on a 600mhz pc that I tried. You seem to be refuting claims I never made. This is a straw man fallacy - misrepresenting my position.
Here is a link: http://en.wikipedia.org/wiki/Strawman

"Example

Straw man arguments often arise in public debates even when less flawed arguments could be found to support the same position.

* (Hypothetical) prohibition debate:

Person A: We should liberalize the laws on beer.
Person B: No, any society with unrestricted access to intoxicants loses its work ethic and goes only for immediate gratification.

The proposal was to relax laws on beer. Person B has exaggerated this to a position harder to defend, i.e., "unrestricted access to intoxicants".[1]"

Please do not misrepresent me in future.

The claim that this was a publicity stunt in favour of C# is ridiculous and shows that you haven't even read the blog posts. Also note that C++ comes on top in the end and Rico profiles the code and shows exactly *why* and *how* this happens.

This is a very informative post if you wish to learn how .Net affects application performance, startup times and memory consumption. I'd suggest reading the posts even though they are written by Microsoft employees - if nothing else, they will give you ammunition to shoot down claims in favor of .Net.

I never said they were a publicity stunt. I am just aware that microsoft controls the output of its employees to the public, as does any company. So will an oil company on the subject of climate change, this is a fact. The link provided may contain useful information but it is in the context and with the intention of showing .net in a positive light (to do otherwise would cost someone their job). I believe in independant sources of information, i'm sorry this upsets you.

A couple of pages back I said this very thing: on your *native* platform the costs are amortized and become negligible. This is why utorrent outperforms ktorrent on win32 (in memory/disk/startup). This is why ktorrent needs only 6.8MB memory to run on a KDE desktop.

I was not infact aware that KTorrent used less than utorrent on KDE. I have really not measured the exact amount of KTorrent vs utorrent recently (it's not exactly something you do daily is it?). I never claimed it ran faster or more efficiently than utorrent, just that
A) It was not noticably any slower than utorrent on Linux or Windows on my 600mhz pc in the other room (which is not the case for monsoon for example) and
B) It did compared to any .net or java application that filled the same role, i'm still waiting for an example from you that disputes this (hint: there are none to show, they dont exist)

What about Python desktop apps, do they perform horribly too? In other words, is your argument purely political or is there some substance hidden somewhere in it?

Give me an example of a significant python app? I can only think of either small apps where you would really not notice (as it doesn't load a world of dependacies like mono for the tiniest thing) or cases where it is used as glue. If you have an example of something where that is different mention it though because I honestly cannot think of one off the top of my head.

Transmission, compizconfig-manager, ati tray tools, paint .net, sharpdevelop are examples of managed applications that run great on my non-SSD machines.

The first two i'll give you, tray tools is "ok" paint.net well....see the other reasons mentioned in this thread but yes that is also true. Out of those only paint.net (possibly sharpdevelop too i've not looked at it in a long time) are that "large" of applications. But see, you're charging the arguement away from .net/mono and intro "managed applications" because your arguement fell apart on the previous topic.

Firefox and Evolution are examples of native applications that run awfully on both my non-SSD *and* my SSD machines.

Firefox renders the entirety of its interface with it's own engine. Show me a .net app that does that or could do that even remotely as quickly as firefox does? That's right, there are none. There is a good reason people don't event attempt to use it for such a thing. I think you can guess. Comparing apples to oranges doesn't really work. Evolution has always been a pig, it still depends on bonobo iirc. I know nothing of the development of Evolution so I can't comment much. I'm glad you've managed to find one, single, exception to the norm though.

Your claim that managed applications must always run worse than native applications is laughable.

I never made that claim, you just did, in this quote. Any well written application in a lower level language has a large inherant performance advantage with few exceptions (notice few, not none - before you misquote me again). I'll link you again incase you missed it: http://en.wikipedia.org/wiki/Strawman

Stop right there, Miguel no longer holds any executive power over Gnome. He is a mere contributor like any other.

Good way of pretending that history doesn't matter. He still has influence and with all the legal reasons cited against mono being the platform for future gnome development gone and a lack of C developers / contributers these days the door is open. As a language I see C# as superior to java - I remember what a horrendous pig java was dealing with it in uni. People are welcome to use it, but I don't want something like that running my entire DE. I guess this last point will only be ended when gnome makes its transition to whatever language it ends up transitioning to.

[BlackStar]

there are simply no examples that back up anything you have said

I'm not concerned with little applications to which you refer

When I give you examples, you suddenly claim that you are not concerned about examples. How disingenious.

It is slightly higher 936kb -ish iirc but this was a while ago. I'm glad you now understand what i said.

I do, but you don't. Is it a lack of reading comprehension or are you consciously ignoring my argument (which makes you a troll)?

To reiterate: using native APIs makes for a smaller and more efficient application. Using cross-platform abstractions (like Qt) makes for larger, less efficient applications.

Never said it wasn't, just that it is as fast as utorrent on a 600mhz pc that I tried. You seem to be refuting claims I never made. This is a straw man fallacy - misrepresenting my position.

I never claimed that ktorrent is less efficient than utorrent as far as CPU is concerned, only as far as memory consumption and disk space and *only* when running on a non-native platform. Go back and reread my posts (that's your lack of reading comprehension I was talking about).

I never said they were a publicity stunt.

Ok, so why don't you read the posts and understand their technical content? Or is that too difficult for you?

Give me an example of a significant python app?

code.google.com and google groups

Edit: I couldn't find a credible (i.e. non-blog) resource on my original suggestion, new suggestions here.

The first two i'll give you, tray tools is "ok" paint.net well....see the other reasons mentioned in this thread but yes that is also true. Out of those only paint.net (possibly sharpdevelop too i've not looked at it in a long time) are that "large" of applications. But see, you're charging the arguement away from .net/mono and intro "managed applications" because your arguement fell apart on the previous topic.

My argument has been about managed vs native applications from the beginning. Also note that since Python is *less* efficient than .Net, if Python is good enough then .Net is too.

So you make yet another argument based upon a lack of reading comprehension.

Firefox renders the entirety of its interface with it's own engine. Show me a .net app that does that or could do that even remotely as quickly as firefox does? That's right, there are none. There is a good reason people don't event attempt to use it for such a thing. I think you can guess. Comparing apples to oranges doesn't really work. Evolution has always been a pig, it still depends on bonobo iirc. I know nothing of the development of Evolution so I can't comment much. I'm glad you've managed to find one, single, exception to the norm though.

The Visual Studio 2010 GUI is based on .Net. You can search for more examples if you wish.

I never made that claim, you just did, in this quote. Any well written application in a lower level language has a large inherant performance advantage with few exceptions (notice few, not none - before you misquote me again). I'll link you again incase you missed it: http://en.wikipedia.org/wiki/Strawman

Good thing you link to that article, read it and maybe you'll understand why your argument is a strawman.

I didn't argue that managed languages are faster. I argued that (a) they are fast enough for the vast majority of cases and (b) the advantage in development time means you can optimize your code and still complete your application sooner than with an unmanaged language.

You try to counter that saying that lower level languages usually (but not always) have a performance advantage. No shit, you are right - but I never argued against that. Who is using a strawman here? (No need to answer that question, by the way).

[XorEaxEax]

UPX claims an average compression level ratio of 0.307:1 (source). Assuming this holds for utorrent, the uncompressed executable would be ~919KB - still smaller than the *bootstrap* installer of ktorrent, which doesn't even contain Qt.

Yes, the executable size is really of no interest since I can write a program in 10k that will end up using 4gb ram.

Transmission, compizconfig-manager, ati tray tools, paint .net, sharpdevelop are examples of managed applications that run great on my non-SSD machines. Firefox and Evolution are examples of native applications that run awfully on both my non-SSD *and* my SSD machines.

Transmission is written in c, paint.net relies on native and very optimized gdi+ to do it's heavy lifting, and things like compizconfig-manager, ati tray tools etc could be written in interpreted language without a noticeable hit since they practically do nothing. And you compare this with a program like Firefox?

Your claim that managed applications must always run worse than native applications is laughable.

Not always, but most likely. No matter how efficient garbage collecting becomes (and it has certainly made great headway) it will be slower than explicit memory management due to the overhead of the logic involved in deciding when a piece of memory is ready to be reclaimed. Other things like automatic bounds checking and not being able to use pointer arithmetic can also have big implications on speed depending on the actual application. Also there's always going to be a delay when starting the program due to JIT compiling the bytecode.

Managed code certainly has some advantages and definitely has it's place, but not if performance is of great importance.

[Hoodlum]

When I give you examples, you suddenly claim that you are not concerned about examples. How disingenious.

No. You, time and again, are ignoring my original statement about it not being possible to use it for anything significant (ie to the platform) due to low performance. This is still the case and you have provided 0 examples where this is not so. You are again arguing with yourself and ignoring my points.

I do, but you don't. Is it a lack of reading comprehension or are you consciously ignoring my argument (which makes you a troll)?

You have ignored mine and misreprested everything I have said throughout. Don't think anyone is as much of a fool to actually be swayed by this statement. Your continual peddling of mono as something that has "acceptable" performance (and then changing the topic to KTorrent memory usage when you have no arguement) is a joke.

To reiterate: using native APIs makes for a smaller and more efficient application. Using cross-platform abstractions (like Qt) makes for larger, less efficient applications.

Yeah it does, but that's again avoiding the issue you seem to keep dancing away from - which is that QT apps aren't so slow that they give the user a lessened experience even on pentium III pcs like the one I have used them on. This is not the case for .net or mono, even on modern (~2 year old) pcs in some cases. Hint: this is what the topic is about, mono.

I never claimed that ktorrent is less efficient than utorrent as far as CPU is concerned, only as far as memory consumption and disk space and *only* when running on a non-native platform. Go back and reread my posts (that's your lack of reading comprehension I was talking about).

So you were discussing another topic? I suggest you make a new thread or respond with something relevent to what the person you quoted has actually said then. The irony.

Ok, so why don't you read the posts and understand their technical content? Or is that too difficult for you?

Go on, what's next? "my daddy could beat your daddy up?" Really i'm in stiches here, you have to resort to this to even respond to me, wow.

My argument has been about managed vs native applications from the beginning.

So you began by responding to my specifically tailored arguement to mono/.net & a few mentions of java with a totally different issue yet again.

Also note that since Python is *less* efficient than .Net, if Python is good enough then .Net is too.

Transmission is a native C app btw. Python is acceptable for small (very simple) tools, and glue. It does not bring in 20mb of depedancies written in python just to run a very small peice of code either (this statement is in reference to a blog aggregated on planet gnome where tomboy was tested against gnote (under 3mb) for memory usage) - feel free to disregard it though.

So you make yet another argument based upon a lack of reading comprehension.

I stupidly assumed your response *TO ME* had some sort of relevence to what *I SAID* or to the topic clearly it did and does not.
You continue arguing something with yourself which no one except you was discussing on a topic about mono (hint: not python). I think this is all on you.

The Visual Studio 2010 GUI is based on .Net. You can search for more examples if you wish.

I'll oversimplify this for you as you don't seem to have understood. firefox renders its interface in many ways as it would a webpage - your example does not. How is this relevent?

I didn't argue that managed languages are faster. I argued that (a) they are fast enough for the vast majority of cases

1) You argued they were not slow. This was false.
2) You never said that.
3) You also never defined "the majority of cases". a pentium 1? a 4096 cpu cray? who knows! Again nothing to back up any of your statements
As said they have been shown not to and it is widely understood by most users that they do not on normal hardware. As these are the actual users they are representitive of what is being used. Your statements are at odds with everyone else on the subject here this shows your ideas have no relevence.

and (b) the advantage in development time means you can optimize your code and still complete your application sooner than with an unmanaged language.

That's a fair statement. You will have more time to optimize an application in C# than you would if you made the same thing in assembly too, but that doesn't mean it would ever reach the same performance level (it wouldn't). That I have to keep repeating something this basic really shows there is little point trying to make you see that this is true.

You try to counter that saying that lower level languages usually (but not always) have a performance advantage. No shit, you are right - but I never argued against that. Who is using a strawman here? (No need to answer that question, by the way).

You seemed to be arguing against QT because it was so bloated and inefficient(not defined until your last post) yet user experience shows that any inefficiency is negligable and has no real impact on *real* users. *Real* use cases. Not some made up theory you have about what the average user uses.

Let me simplify this even more for you as you are not getting it:
Q) Why do people complain about .net and mono being slow?
A) Because it is slow for their use case.

Guess what? users know the difference between "fast" and "slow", "acceptable" and "not"! Are you really trying to suggest every user that does not like the performance of mono/.net apps is just wrong? Please, your arrogance astounds me.

[BlackStar]

Not No matter how efficient garbage collecting becomes (and it has certainly made great headway) it will be slower than explicit memory management due to the overhead of the logic involved in deciding when a piece of memory is ready to be reclaimed. Other things like automatic bounds checking and not being able to use pointer arithmetic can also have big implications on speed depending on the actual application. Also there's always going to be a delay when starting the program due to JIT compiling the bytecode.

Managed code certainly has some advantages and definitely has it's place, but not if performance is of great importance.

By default, memory management in .Net is more efficient than memory management in C++ in three significant regards: faster allocations, no memory fragmentation and reduced danger of a memory leak. Calling new in C++ or malloc in C is significantly slower than calling new in C#. Moreover, C# supports pointer arithmetic in unsafe contexts, as well as manual memory management (via Marshal.AllocHGlobal() and pointer arithmetic). It can allocate stack memory which doesn't involve the GC at all.

C++ has several advantages over C# (or .Net in general), but memory management is simply *not* one of them.

Note that you can avoid startup delays by AOT compiling .Net CIL bytecode to native binaries. This removes the JIT from the equation and brings startup times close to C++ levels.

Once again, I'm not claiming that managed code is better than unmanaged in all cases, but for desktop applications it almost certainly is. Hell, if it's good enough for applications like Visual Studio, Second Life or Wikipedia (the search function), then it's good enough for me.

Hoodlum, do you also consider Wikipedia as not "anything significant"? Suit yourself, I've given more than enough examples here, which you keep ignoring. Have fun with Gnote!

[Hoodlum]

Once again, I'm not claiming that managed code is better than unmanaged in all cases, but for desktop applications it almost certainly is.

Clearly ignoring all the cases mentioned throughout the entire thread where it isn't and not a single one where it was.

Hell, if it's good enough for applications like Visual Studio, Second Life or Wikipedia (the search function), then it's good enough for me.

Hoodlum, do you also consider Wikipedia as not "anything significant"?
Suit yourself, I've given more than enough examples here, which you keep ignoring. Have fun with Gnote!

1) When you have an example that fits any of the defined statements I made call me (you haven't yet),
2) Wikipedia isn't analogous with .net / mono. This is a false assumption.
3) A generic search function is not significant - it can be implemented in nearly any language reasonably well. This is also not verifiable.
4) I'm happy with my first life thank you, enjoy your second and
5) I don't use gnote. this is :

Poisoning the well: where adverse information about a target is pre-emptively presented to an audience, with the intention of discrediting or ridiculing everything that the target person is about to say

http://en.wikipedia.org/wiki/Poisoning_the_well

People tend to do this when they lack any kind of counter point or arguement.

[XorEaxEax]

By default, memory management in .Net is more efficient than memory management in C++ in three significant regards: faster allocations, no memory fragmentation and reduced danger of a memory leak. Calling new in C++ or malloc in C is significantly slower than calling new in C#. Moreover, C# supports pointer arithmetic in unsafe contexts, as well as manual memory management (via Marshal.AllocHGlobal() and pointer arithmetic). It can allocate stack memory which doesn't involve the GC at all.

The VM manages it's own memory heap, so it allocates a large chunk of memory and allocates from that. A native app can do this aswell, and more efficiently since the programmer has full control. Also memory fragmentation occurs in managed code aswell, pinned objects will prevent the compaction. And as always, the memory defragmentation that the compacting performs does not come for free, since it MOVES data within the heap. You seem to think these things are somehow done by magic, there's a cost to all these things.

Note that you can avoid startup delays by AOT compiling .Net CIL bytecode to native binaries. This removes the JIT from the equation and brings startup times close to C++ levels.

But then you lose the advantage of deployable bytecode which is one of the big selling points of managed code.

[smitty3268]

I am a little confused by Blackstar's position here.

On the one hand, he seems to be arguing that KTorrent sucks in comparison to uTorrent because it doesn't use the native libraries and uses lots of disk/memory space.

Yet on the other he seems to be defending the use of Mono on the Linux desktop, ignoring the fact that the biggest negative of managed apps are the bloated memory requirements and the disk space the non-native libraries take up.

I use managed apps for little utilities all the time and they seem to work pretty well, but until I see more large applications that run well I'm going to remain skeptical. Perhaps VS2010 will manage to do it.

One of the things that the managed memory means is that overall the avg cost of a memory operation is quite a bit better than a normal app (meaning throughput goes up) but running a whole bunch of queued operations at once can cause an interactive application problems. A thousand slower allocations in C++ might seem faster to the user than a single garbage collection if the programmer isn't careful because each one individually might not be noticed. One of the big areas of research right now is getting memory managers to bahave better - spinning them off into seperate threads, running them incrementally, etc.

[BlackStar]

I am a little confused by Blackstar's position here.

On the one hand, he seems to be arguing that KTorrent sucks in comparison to uTorrent because it doesn't use the native libraries and uses lots of disk/memory space.

I never said ktorrent sucks (if I did please find a quote).

I responded to someone who said two things: (a) utorrent is a great example of an efficient application (I agree) and (b) Qt can help you reach that level of efficiency (I disagree, simply because Qt adds significant overhead - bloat if you will - when running on a non-native platform). I compared ktorrent with utorrent on Windows to provide an example of this non-trivial overhead as far as disk space is concerned. Kraftman compared the actual memory consumption: ktorrent loses on Windows (presumably due to Qt), while it wins on its native platform, KDE.

Again, I have nothing against Qt, it is a great toolkit. I merely wanted to explain that using any non-native GUI toolkit/ platform abstraction/helper library (Qt, Java, .Net, whatever) will add overhead over a native application. To reach the level of utorrent, you have to bite the bullet and get your hands dirty with native APIs.

Yet on the other he seems to be defending the use of Mono on the Linux desktop, ignoring the fact that the biggest negative of managed apps are the bloated memory requirements and the disk space the non-native libraries take up.

Indeed. Utorrent may be one of the most efficient applications out there, but I don't believe it reasonable to expect all applications to be written like that. For some, it makes sense to use a cross-platform toolkit like Qt. For others, it makes sense to reduce development time using Mono, Java or Python. For yet others it might make sense to use a mix of techniques (most games use a hand-optimized native core and managed languages for everything else: UI, AI, event scripting, in other words the actual game).

I use managed apps for little utilities all the time and they seem to work pretty well, but until I see more large applications that run well I'm going to remain skeptical. Perhaps VS2010 will manage to do it.

One of the things that the managed memory means is that overall the avg cost of a memory operation is quite a bit better than a normal app (meaning throughput goes up) but running a whole bunch of queued operations at once can cause an interactive application problems. A thousand slower allocations in C++ might seem faster to the user than a single garbage collection if the programmer isn't careful because each one individually might not be noticed. One of the big areas of research right now is getting memory managers to bahave better - spinning them off into seperate threads, running them incrementally, etc.

(I assume by managed you mean .Net/Mono here, rather than managed runtimes in general, which are proven and well respected in many different fields)

I agree 100%.

.Net and especially Mono are relatively young players as far as managed runtimes are concerned. Even so, they are used in fields such as web services, many smaller and a few larger desktop applications, commercial games (Mono runs on the Wii, the PS3, the iPhone and is known to be used by Unity3d, the Second Life and the Sims 3). Not too shabby, I'd say.

The VM manages it's own memory heap, so it allocates a large chunk of memory and allocates from that. A native app can do this aswell, and more efficiently since the programmer has full control. Also memory fragmentation occurs in managed code aswell, pinned objects will prevent the compaction. And as always, the memory defragmentation that the compacting performs does not come for free, since it MOVES data within the heap. You seem to think these things are somehow done by magic, there's a cost to all these things.

There is no such thing as a free lunch.

I have actually measured and *know* what the GC overhead is on the applications I am working on. This is a parameter that can be optimized like anything else, although in my experience this is not necessary for most apps. (Aside from apps that need very stable performance, e.g. games/VR targeting 60fps hard, or apps that need the highest possible throughput, e.g. image recognition or encoding software, the GC rarely appears in the profiler).

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!

But then you lose the advantage of deployable bytecode which is one of the big selling points of managed code.

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.

@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.

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.

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.

[kraftman]

Kraftman compared the actual memory consumption: ktorrent loses on Windows (presumably due to Qt), while it wins on its native platform, KDE.

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)? :>

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.

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.