Mono 2.10, Moonlight 4 Preview 1 Released

[smitty3268]

Ever tried looking for a job in software engineering? Java/C#/PHP/Python/Javascript outnumber C/C++ 10 to 1.

The vast majority of those jobs are for apps running on servers or inside a company. The numbers are the opposite when it comes to applications intended to be sold to consumers.

Anyway, I agree that C# is Java done right. They've added a bunch of little C++ features into it that Java left out, but there's no question which ones are closer to each other.

But couldn't disagree more strongly with your assertion that if everything was written in .net memory usage wouldn't go up at all. That's crazy talk, there. I wouldn't be too worried about CPU (at least for the vast majority of applications) but I've never seen a managed code app do anywhere close to decent in terms of memory usage. I'm sure it has a lot to do with the way everything is managed off the heap and sticks around. Maybe eventually this is a problem that languages can solve, but it hasn't happened yet.

[smitty3268]

Phoronix, you still suck.

You STILL can't edit posts.

The vast majority of those jobs are for apps running on servers or inside a company. The numbers are the opposite when it comes to applications intended to be sold to consumers.

Which suggests that languages like .NET are very good for developer productivity, but not so good for making apps that don't annoy people (i.e. bad responsiveness, high resource requirements, etc.)

[RealNC]

Javascript improvements are in the order of ms. Network latencies total in seconds for modern websites with multiple scripts and image elements. Browsers are definitely network-bound - but browser makers cannot do anything about that so they focus on secondary bottlenecks instead.

Try JavaScript games in Chrome, for example. Or GMail. If you like having a browser that is slow as molasses, that's your right. I prefer a fast, fluid browser. Those "secondary" bottlenecks count too. And with more apps moving to the web and using JavaScript/AJAX, this is becoming more and more important.

You can argue all day long, but speed matters in browsers.

No, really not. I've been using VBox and VMWare for years and disk performance is by far the slowest part. CPU plays a role but it's quite small (VBox performs almost identically on my dual-core Core 2 and my quad-core Phenom 2 in actual use).

If virtualization in VMWare and vbox wasn't optimized like hell already (because virtualization is inherently CPU- and memory throughput-bound, and needs good resource and memory management, you know, the stuff C# does away with), disk speed would be the least of your worries. If clicking that start menu inside a Windows 7 guest would take 2 seconds to register, you wouldn't care about disk speed.

And btw, how can vmware (or whatever) be disk-bound anyway. It's like saying your whole PC is disk-bound. Well, yeah, duh! Your host OS is too. But there's nothing *inherently* disk bound in virtualization.

All three languages share syntax, but C# really is much closer to Java than C++

Sorry, I'll take the word of the persons who invented C# over yours. No offense.

Ever tried looking for a job in software engineering? Java/C#/PHP/Python/Javascript outnumber C/C++ 10 to 1.

Yes, that's web development. Software-engineering is not just web development. And no one is arguing here that you should develop web apps in C, so what exactly was your point here?

[BlackStar]

The vast majority of those jobs are for apps running on servers or inside a company. The numbers are the opposite when it comes to applications intended to be sold to consumers.

Well, most user-facing applications I've had to buy recently actually installed .Net, so I'd argue that's not quite correct. In any case, server and internal line-of-business apps probably outnumber end-user apps by an order of magnitude or so - and those LOBs tend to be written in .Net et al today.

But couldn't disagree more strongly with your assertion that if everything was written in .net memory usage wouldn't go up at all. That's crazy talk, there.

You'd be right if I had ever said that.

I wouldn't be too worried about CPU (at least for the vast majority of applications) but I've never seen a managed code app do anywhere close to decent in terms of memory usage. I'm sure it has a lot to do with the way everything is managed off the heap and sticks around. Maybe eventually this is a problem that languages can solve, but it hasn't happened yet.

Virtual memory indeed goes way up, because .Net reserves around 10MB for each app on startup. However, this memory isn't committed until it's actually used - you may run out of address space sooner (a non-issue with 64bit CPUs) but you won't run out of memory because of this. Virtual memory != memory usage (don't trust your task manager).

You get a fixed memory overhead for the runtime and BCL, which is amortized among all managed applications. This is trivial anyway (in the order of single-digit MBs) and the more managed applications you run, the less important it becomes.

You get *decreased* memory fragmentation which is the largest issue for long-running applications (fragmentation acts like an insidious memory leak that can cause an app to run out of memory even when enough free memory exists).

Finally, .Net supports both stack and heap allocations (unlike Java which always goes to the heap unless the runtime can guess correctly). Stack allocations are actually an important part of performance-oriented .Net code.

(That said, most of the issues with Mono memory usage stem from the god-awful GTK# bindings, not from the runtime itself.)

Sorry, I'll take the word of the persons who invented C# over yours. No offense.

You really didn't understand what he was actually comparing, I'm afraid. Try rereading that blurb and refer smitty3268's post for clarification.

Yes, that's web development. Software-engineering is not just web development. And no one is arguing here that you should develop web apps in C, so what exactly was your point here?

Who said anything about web development? Let me ask you again: have you tried looking for any softeng jobs recently?

The offerings for C++ are slowly but surely going down.

[ciplogic]

@RealNC
In my experience JS is by far not the fastest thing I can think: AdBlock makes for certain much snappier those webpages (in FF 3.6 compared with last Chrome without enabling the AdBlock extension), the fact to not start any extra plugins (like flash on most sites excluding the main view of Youtube). Did you ever tried GMail on IE8 (not 9)? I really felt it snappier (I'm not a fan of IE8 in anyway) and for certain it runs in an interpreter. A JIT will help, but certainly, even IE9 is the *slowest* of all JIT JS around there, in all benchmarks that are in their site they shine! Because they have a lot of systems optimized for browsers. They show that sometimes a browser can be GPU bound and in a lesser measure CPU bound.
Even it will be, JS works like 10 times slower (at best!) than C++ (compared with Mono/.Net that is in 1.5-2x slower on typical usage). So why people use JavaScript? Because is not native, it's GCed, JIT-ted and *productive*.
About responsivity, memory resources and so: did you ever measure those? Or you work just with biases like: you start a big application as NetBeans, and you conclude that start slower than GEdit, so it means that Java *sux*? A desktop project I work on removed a framework (SCSF) and rewrite that part in it's "raw" implementation (this was not because we wanted to run fast, the reasons were for other technical reasons) and the project I'm working gained around 2 seconds on startup. In the last time profiling of that application it runs like this: 3.5 seconds start time from which identifiable time is like: loading libraries, UI layouting, start OpenGL subsystem, Direct3D one, browser control one (used for help). .Net identifiable overhead? Around 0.2 seconds.
Did you heard about Magika? Is a .Net game. I don't wanna you to play it, it will likely not run in Wine. What about XPand Rally? Its a rally game engine is written in Java. I think even if you will be put in front of real numbers (which most people don't care) you will see that probably Java/.Net/JS are not the best performers (in your specific benchmark) may be just enough to a lot of use-cases.
Even you will may say: look, Magika don't use C# everywhere, it will eventually go to GPU that is written in C++/asm/whatever, or kernel. This is all about! Is about to use proper tool for proper job. Sometimes, if you are on a small team, you stay one week (or one month), investigate the overhead of a technology and peek the leanest one. Can be sometimes to not be C++? For certain, because overhead comes from: build times, "nice" template errors, hard to write and to read code, linker errors, IDEs that don't have proper refactors, memory leaks, slow performance if you use STL and you will get bounds checking that is not removed by your compiler, or simply that you copy all collection instead of sending "const references", slow performance on reference counted code like smart pointers (mostly in loops), relatively hard to find a generic driver for Sql (probably Qt is the single option, if you don't want to work directly with SqlLite, MySql and so on), high skilled personnel just to start your project, no static check analyzers for your code.
Don't take my word for it but you may find millisecond range high performance transaction code in Java (like in London Stock Exchange), aviation (that have both real-time requirements and robustness), a lot of banking systems (replacing mostly Cobol/C/C++ codebases).
I also recommend to you to start two tools side by side with similar functionality: Visual C# Express and SharpDevelop. C# Express is mostly written in C++, when SharpDevelop is completely written in C#. Judge for yourself which is faster (take SharpDevelop 3 to compare with VS 2008, and SD 4 to compare with VS 2010 as they have similar technologies inside them). At least on my machine, SD starts a bit faster, and after this in almost all operations is MUCH faster than C++ counterpart: build times, navigating through classes and so on.
If you just use Linux as you hate Microsoft, try Pinta with Krita. I do think you will hate Pinta (cause of Mono), but regardless of your preference, judge performance using the same measure: both code is unlikely written in assembler so you will get similar timings. Also, if you find an operation that Pinta is slow, I recommend you to run in Mono/LLVM to get better timings.

[smitty3268]

You'd be right if I had ever said that.

Previously:

Take a good look at your Linux and/or Windows installation. Most programs are not running in a VM. Now imagine how well that system would run if everything was running inside .NET. What would the memory and CPU usage look like?

Identical, quite likely. The BCL can be shared between applications and 99.9% of them are not CPU-bound anyway.

Sounds to me like that's exactly what you said.

[BlackStar]

Previously:

Take a good look at your Linux and/or Windows installation. Most programs are not running in a VM. Now imagine how well that system would run if everything was running inside .NET. What would the memory and CPU usage look like?

Identical, quite likely. The BCL can be shared between applications and 99.9% of them are not CPU-bound anyway.

Sounds to me like that's exactly what you said.

What I said: the cost of one application vs multiple applications is identical (the VM is shared).

What you understood: the VM doesn't have a cost.

I didn't say what you thought I said.

Applications themselves don't start using more memory just because you run them inside a VM: a pointer is a pointer, a vtable is a vtable and a bitmap is a bitmap no matter what (in fact, Java can actually compress pointers to reduce memory usage, but that's beside the point). The cost comes from the VM, which is amortized among all applications - the more managed applications you run, the more the VM cost is amortized.

[ciplogic]

Why I don't want mono on Linux:
it's slow, it's crap from ms ...

I've tried to put your wording on test. Mostly on slow part which is a part of concern.
So I've took one multi-language mini-benchmark (to be fair, was the first on order of relevance that I found) about computing Pi digits.
As many may found is mostly integer + string operations that match most of today desktop application benchmarks.
So the benchmark was published around 10 years ago, showing that likely picking C++ or C was the best choice, C#/Delphi may be a good choice that in any way was better than Java.
Here is the benchmark and source-codes on reference: http://www.tempest-sw.com/benchmark/
As a lot of people will find limiting the high values of benchmark, also making things to distant as much as possible (what is the difference between 170 ms against 230 ms for 2000 digits on my machine? I cannot spot with my eyes, to be fair).
My machine is in short i5-540M, a lot of RAM, Win7 64. I've used against runtimes I found just once to download and I've excluded Python, Perl and so on, which will be slower than Mono and .Net.

So I've computed all benchmarks with arguments: 20000 out.txt (meaning compute Pi with 20000 digits and write the output to out.txt) and this is the timing:
.Net 3.5SP1/4.0 (32 bit): 20935 ms.

Mono 2.10:
mono --gc=sgen --llvm TimmedPi.exe (32 bit): 20608 ms.
mono --gc=sgen -O=all TimmedPi.exe (32 bit): 21028 ms.

JDK 7.0 (64 bit): 15584 ms. I did install 32 bit but cause of my incompetence I've got class not found at startup, I really ask anyone who wants to test this code to do it.
VS/C++ 2010, I've got the best timing based on all options I found on Release configuration, and I've checked a lot!: C++: 17738 ms
So, Java is the *fastest* here and:
- C++ is 13.82% slower than Java
- C#/Mono/LLVM: 32.24 % slower than Java / 16.17% slower than C++
- C#/.Net: 34.33 % slower than Java / 18.02% slower than C++
- C#/Mono: 34.93 % slower than Java / 18.54% slower than C++

I've tried timings on Linux but I think I've did something terribly wrong and GCC gets on my machine around 25 seconds (so it gets worse than Mono), Mono timing remains constant and Java is around 16.5-17 seconds (again the fastest). The reason I don't want to show those results to make people to try by themselves those "benchmarks" and to notice how right they are and based on those to get the right conclusion.
Will you not use an easier to use language (as C#) if you will know from scratch that will run around 20-35% times slower than the best optimized platform you can run, if you feel comfortable in it?

[smitty3268]

What I said: the cost of one application vs multiple applications is identical (the VM is shared).

What you understood: the VM doesn't have a cost.

I didn't say what you thought I said.

Applications themselves don't start using more memory just because you run them inside a VM: a pointer is a pointer, a vtable is a vtable and a bitmap is a bitmap no matter what (in fact, Java can actually compress pointers to reduce memory usage, but that's beside the point). The cost comes from the VM, which is amortized among all applications - the more managed applications you run, the more the VM cost is amortized.

No, what was said that running everything in the system in .NET would result in a big memory usage increase. You then replied it wouldn't. And now in your last response, i'm not even sure what your final position was.

So, I'll just ask clearly again: Everything running in .NET, memory usage goes way up? Or not? You have 1 word to reply.

[smitty3268]

I've tried timings on Linux but I think I've did something terribly wrong and GCC gets on my machine around 25 seconds (so it gets worse than Mono), Mono timing remains constant and Java is around 16.5-17 seconds (again the fastest). The reason I don't want to show those results to make people to try by themselves those "benchmarks" and to notice how right they are and based on those to get the right conclusion.
Will you not use an easier to use language (as C#) if you will know from scratch that will run around 20-35% times slower than the best optimized platform you can run, if you feel comfortable in it?

You should be very careful drawing conclusions from these sorts of micro-benchmarks. What you've shown isn't that a language is 30% faster than another one, but just that its compiler has an optimization for that specific case being tested which is 30% faster. The situation could be completely reversed on another benchmark.