6 ms·

Compare the choice of garbage collectors and high performance JVM implementations vs what the CLR offers. I don't have recent benchmarks for the MS implementati

Compare the choice of garbage collectors and high performance JVM implementations vs what the CLR offers. I don't have recent benchmarks for the MS implementation of the CLR, but Mono lags noticeably behind Java in terms of performance: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=java http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

localhost 14y ago
Mono is a completely different implementation from the CLR. I wouldn't be so quick to discount the CLR's GC.
- bad_user 14y ago
  Microsoft disallows .NET benchmarks. If you want to compare Java and .NET you have to have their approval first.
  - UnoriginalGuy 14y ago
    Can you cite that? It sounds like an odd thing to do/suggest. I'm not even sure how Microsoft would stop people even if they wanted to...
    - bad_user 14y ago
      I was wrong, they changed the EULA in the meantime. Here are the conditions I could find (you still have to comply with those conditions, but it's doable): http://msdn.microsoft.com/en-us/library/ms973265.aspx http://msdn.microsoft.com/en-us/library/ms973265.aspx And they can stop you through the EULA .NET gets distributed under, because no other license gives you the right to use .NET, so you have to do it under the terms of that license.
- thebluesky 14y ago
  I find it interesting that when folks want to claim that .NET is crossplatform they cite Mono, but when performance is discussed they are only prepared to discuss the performance of the MS Windows implementation provided by MS. The last time I benchmarked .NET (on Windows) it was significantly slower than java (with -server flag), but their EULA forbid publishing benchmark results at the time (was a long time ago, but since the parent is discussing .NET v1.0 and it's creation...)
  - deleted 14y ago
    [deleted]
- rabbitfang 14y ago
  The MS CLR is also significantly slower than Java: http://shootout.alioth.debian.org/demo/benchmark.php?test=all&lang=csc&lang2=java http://shootout.alioth.debian.org/demo/benchmark.php?test=al...
rbehrends 14y ago
The situation is a bit more complicated than that. To begin with, there are basically three CLR backends with sufficient maturity: Microsoft.NET, Mono, and Mono/LLVM, of which Mono is probably the slowest, because it is optimized for fast startup; that is matched against java -server, which (unlike -client) does extra optimizations (like mono --llvm) at the expense of a slower startup time. This works for short benchmarks, because compilation time is fairly minimal for these tight-inner-loop benchmarks. Second, none of these benchmarks really touch on any of the JVM's weak spots. The classical example here is complex number arithmetic, where even an addition can potentially trigger a heap allocation (the JVM escape analysis only helps as long as functions don't actually store results anywhere). There are unfortunately quite a few such features where you get extra overhead to implement the workarounds. Third, the JVM tends to be a bit of a memory guzzler. Combined with java -server's fixed-size heap, that can create problems in some scenarios (such as a system process that forks a few instances of itself). In the end, few people will pick one or the other for the raw performance (which, in the end, is not very far apart), but for the ecosystem that comes with each backend. It is worth noting that there are also other VM-related concerns, and overall, the CLR has the superior design as a general-purpose language backend. For example, CLR functionality is a superset of JVM functionality. That makes the CLR far more pleasant to use as a compiler backend than the JVM (the reason why JVM-based languages use the JVM primarily is probably to hook into the JVM ecosystem, not because they love devising workarounds to implement closures or value types somewhat efficiently). Similarly, P/Invoke is in practically all aspects superior to JNI. If you need to call native code a lot, P/Invoke is almost always the easier way to do it. Library versioning is another issue where the CLR has the better story. Again, what will almost certainly drive the use of one or the other for 99% of all programmers is what infrastructure (frameworks, libraries) they need. If they want to develop web applications using Scala/Lift, the JVM it is. If you want to implement games using Unity, you're going to use the CLR. The benefits you get from reusing code will almost certainly dwarf other concerns.
- nobleach 14y ago
  Not to mention that an out of the box .NET/CLR will just run fairly well. An out of the box JVM may or may choke, depending on the app you're trying to deploy. I've spent so much time trying to tune our JVMs for performance, that sometimes it's nice just to deploy a C# app on the CLR and have it just "work".

localhost 14y ago

Mono is a completely different implementation from the CLR. I wouldn't be so quick to discount the CLR's GC.

bad_user 14y ago
Microsoft disallows .NET benchmarks. If you want to compare Java and .NET you have to have their approval first.
- UnoriginalGuy 14y ago
  Can you cite that? It sounds like an odd thing to do/suggest. I'm not even sure how Microsoft would stop people even if they wanted to...
  - bad_user 14y ago
    I was wrong, they changed the EULA in the meantime. Here are the conditions I could find (you still have to comply with those conditions, but it's doable): http://msdn.microsoft.com/en-us/library/ms973265.aspx http://msdn.microsoft.com/en-us/library/ms973265.aspx And they can stop you through the EULA .NET gets distributed under, because no other license gives you the right to use .NET, so you have to do it under the terms of that license.
thebluesky 14y ago
I find it interesting that when folks want to claim that .NET is crossplatform they cite Mono, but when performance is discussed they are only prepared to discuss the performance of the MS Windows implementation provided by MS. The last time I benchmarked .NET (on Windows) it was significantly slower than java (with -server flag), but their EULA forbid publishing benchmark results at the time (was a long time ago, but since the parent is discussing .NET v1.0 and it's creation...)
- deleted 14y ago
  [deleted]
rabbitfang 14y ago
The MS CLR is also significantly slower than Java: http://shootout.alioth.debian.org/demo/benchmark.php?test=all&lang=csc&lang2=java http://shootout.alioth.debian.org/demo/benchmark.php?test=al...

rbehrends 14y ago

The situation is a bit more complicated than that. To begin with, there are basically three CLR backends with sufficient maturity: Microsoft.NET, Mono, and Mono/LLVM, of which Mono is probably the slowest, because it is optimized for fast startup; that is matched against java -server, which (unlike -client) does extra optimizations (like mono --llvm) at the expense of a slower startup time. This works for short benchmarks, because compilation time is fairly minimal for these tight-inner-loop benchmarks. Second, none of these benchmarks really touch on any of the JVM's weak spots. The classical example here is complex number arithmetic, where even an addition can potentially trigger a heap allocation (the JVM escape analysis only helps as long as functions don't actually store results anywhere). There are unfortunately quite a few such features where you get extra overhead to implement the workarounds. Third, the JVM tends to be a bit of a memory guzzler. Combined with java -server's fixed-size heap, that can create problems in some scenarios (such as a system process that forks a few instances of itself). In the end, few people will pick one or the other for the raw performance (which, in the end, is not very far apart), but for the ecosystem that comes with each backend. It is worth noting that there are also other VM-related concerns, and overall, the CLR has the superior design as a general-purpose language backend. For example, CLR functionality is a superset of JVM functionality. That makes the CLR far more pleasant to use as a compiler backend than the JVM (the reason why JVM-based languages use the JVM primarily is probably to hook into the JVM ecosystem, not because they love devising workarounds to implement closures or value types somewhat efficiently). Similarly, P/Invoke is in practically all aspects superior to JNI. If you need to call native code a lot, P/Invoke is almost always the easier way to do it. Library versioning is another issue where the CLR has the better story. Again, what will almost certainly drive the use of one or the other for 99% of all programmers is what infrastructure (frameworks, libraries) they need. If they want to develop web applications using Scala/Lift, the JVM it is. If you want to implement games using Unity, you're going to use the CLR. The benefits you get from reusing code will almost certainly dwarf other concerns.

nobleach 14y ago
Not to mention that an out of the box .NET/CLR will just run fairly well. An out of the box JVM may or may choke, depending on the app you're trying to deploy. I've spent so much time trying to tune our JVMs for performance, that sometimes it's nice just to deploy a C# app on the CLR and have it just "work".