5 ms·

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 Mon

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".
bad_user 14y ago
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). That's not true. The JVM has inherent advantages that the CLR does not have ... (1) the JVM can inline virtual method calls and with some machinery attached (bytecode manipulation) you can get pretty close to zero overhead when invoking functions dynamically (the reason for why dynamic languages on top of the JVM have been pretty awesome) On implementing closures efficiently ... you should check your facts, because delegate invocation on top of .NET always has overhead compared to plain method invocation, while on top of the JVM you can make it so that those invocations will be inlined at runtime (in server mode the JVM even inlines method calls made through plain reflection, which is considered extremely expensive). Implementations such as JRuby successfully do this, but because of JRuby's nature, the call-stack sometimes gets too tall, beyond the capabilities of the JVM to inline, however this is addressed with the InvokeDynamic support from JDK 7, which will make dynamic method calls as efficient as normal calls. Because the CLR is not capable of such optimizations, compiler authors have to do a lot of optimizations ahead-of-time, while on the JVM even a dumb compiler can produce good results ... for proof, compile 2 binaries from the same source-code, one with the Mono compiler, the other one with the official compiler, then run on the same platform and compare. (2) compiler writers love the Jar/.class formats, being really easy to produce binaries for Java, coupled with the maturity of libraries such as ASM ... contrast this with the CLR .dll format, for which the .pdb format for attaching debugging symbols is proprietary and NOT documented, which pushed the people working on Mono to come up with their own format (.mdb). Of course, through reverse engineering and through some code that Microsoft published, the interoperability of Mono with .pdb has improved lately, but it's still painful. (3) there are many tools available for the JVM that complement compiler authors, tools like ObjectWeb's ASM, which have poor substitutes for .NET. And if you want a good parser generator, there are plenty to choose from for Java, while for .NET the only reasonable choice being Antlr, which is primarily a Java tool that also supports .NET -- on the other hand if you wanted to express your grammar with PEGs I personally couldn't find an option for .NET, while there are several available for the JVM. (4) the features in .NET that are not used in C# have received poor support. For instance tail calls were NOT guaranteed to be eliminated, even if you specified this behavior in the compiled bytecode. But more than this, tail-calls have severe overhead over plain method calls. And did I mention that tail-call optimizations, as produced by the F# compiler, simply won't work reliably on Mono? On value types, this is not such a huge issue as many people think. In Scala there's the proposal SIP 15 (value classes) which are implemented in the latest Scala 2.10 milestone release. This will open the door to much needed primitives, like unsigned ints: http://docs.scala-lang.org/sips/pending/value-classes.html http://docs.scala-lang.org/sips/pending/value-classes.html Also, you're making a mistake if you think the CLR type system doesn't have flaws. For instance the CLR lacks a Union type, which makes it a bitch to implement lazy languages, such as Haskell. The CLR also lacks anything that would aid in implementing continuation-passing-style. The JVM doesn't have anything for it either, however for the JVM exceptions can be used for unwinding the call-stack efficiently and compared with the CLR, exceptions on the JVM are very, very cheap. This coupled with bytecode manipulation and library authors have been able to build libraries that make use of CPS efficiently. (5) P/Invoke is basically JNA ... https://github.com/twall/jna https://github.com/twall/jna C# does make it easier because it has a couple of primitives that make the marshaling of data easier.
igouy 14y ago
>>matched against java -server, which (unlike -client) does extra optimizations<< FWIW On a quad-core machine -server is the default.
igouy 14y ago
>>Mono/LLVM<< What a pain! -- "configure: error: Compiling with stock LLVM is not supported, please use the Mono LLVM repo at https://github.com/mono/llvm https://github.com/mono/llvm, with the GIT branch which matches this version of mono, i.e. 'mono-2-10' for Mono 2.10."

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

bad_user 14y ago

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). That's not true. The JVM has inherent advantages that the CLR does not have ... (1) the JVM can inline virtual method calls and with some machinery attached (bytecode manipulation) you can get pretty close to zero overhead when invoking functions dynamically (the reason for why dynamic languages on top of the JVM have been pretty awesome) On implementing closures efficiently ... you should check your facts, because delegate invocation on top of .NET always has overhead compared to plain method invocation, while on top of the JVM you can make it so that those invocations will be inlined at runtime (in server mode the JVM even inlines method calls made through plain reflection, which is considered extremely expensive). Implementations such as JRuby successfully do this, but because of JRuby's nature, the call-stack sometimes gets too tall, beyond the capabilities of the JVM to inline, however this is addressed with the InvokeDynamic support from JDK 7, which will make dynamic method calls as efficient as normal calls. Because the CLR is not capable of such optimizations, compiler authors have to do a lot of optimizations ahead-of-time, while on the JVM even a dumb compiler can produce good results ... for proof, compile 2 binaries from the same source-code, one with the Mono compiler, the other one with the official compiler, then run on the same platform and compare. (2) compiler writers love the Jar/.class formats, being really easy to produce binaries for Java, coupled with the maturity of libraries such as ASM ... contrast this with the CLR .dll format, for which the .pdb format for attaching debugging symbols is proprietary and NOT documented, which pushed the people working on Mono to come up with their own format (.mdb). Of course, through reverse engineering and through some code that Microsoft published, the interoperability of Mono with .pdb has improved lately, but it's still painful. (3) there are many tools available for the JVM that complement compiler authors, tools like ObjectWeb's ASM, which have poor substitutes for .NET. And if you want a good parser generator, there are plenty to choose from for Java, while for .NET the only reasonable choice being Antlr, which is primarily a Java tool that also supports .NET -- on the other hand if you wanted to express your grammar with PEGs I personally couldn't find an option for .NET, while there are several available for the JVM. (4) the features in .NET that are not used in C# have received poor support. For instance tail calls were NOT guaranteed to be eliminated, even if you specified this behavior in the compiled bytecode. But more than this, tail-calls have severe overhead over plain method calls. And did I mention that tail-call optimizations, as produced by the F# compiler, simply won't work reliably on Mono? On value types, this is not such a huge issue as many people think. In Scala there's the proposal SIP 15 (value classes) which are implemented in the latest Scala 2.10 milestone release. This will open the door to much needed primitives, like unsigned ints: http://docs.scala-lang.org/sips/pending/value-classes.html http://docs.scala-lang.org/sips/pending/value-classes.html Also, you're making a mistake if you think the CLR type system doesn't have flaws. For instance the CLR lacks a Union type, which makes it a bitch to implement lazy languages, such as Haskell. The CLR also lacks anything that would aid in implementing continuation-passing-style. The JVM doesn't have anything for it either, however for the JVM exceptions can be used for unwinding the call-stack efficiently and compared with the CLR, exceptions on the JVM are very, very cheap. This coupled with bytecode manipulation and library authors have been able to build libraries that make use of CPS efficiently. (5) P/Invoke is basically JNA ... https://github.com/twall/jna https://github.com/twall/jna C# does make it easier because it has a couple of primitives that make the marshaling of data easier.

igouy 14y ago

>>matched against java -server, which (unlike -client) does extra optimizations<< FWIW On a quad-core machine -server is the default.

igouy 14y ago

>>Mono/LLVM<< What a pain! -- "configure: error: Compiling with stock LLVM is not supported, please use the Mono LLVM repo at https://github.com/mono/llvm https://github.com/mono/llvm, with the GIT branch which matches this version of mono, i.e. 'mono-2-10' for Mono 2.10."