Comment by barrkel
11 years ago
It's not that simple. The CLR has a different feature set to the JVM; or rather, it has a feature superset. If you run Java-like code on the CLR, I would expect it to not be as fast or have as high GC throughput as Hotspot, especially if the Java code has been tuned to Hotspot - there are particular fast paths for certain operations that kick in, where if your code is a little bit too far from the optimized idiom, you end up 3-5x slower. For regular code, I wouldn't expect a big gap between CLR and JVM; a lot of Java code is dominated by pointer chasing because the primary tool of abstraction is a heap-allocated object. C# written in the same way will be bottlenecked in similar ways on cache misses, TLB misses, etc.
There's a larger variety of JVMs designed for a broader range of hardware, the most interesting to me being Azul and their GC tech.
But the CLR gives you some different tactical options. Value types and unsafe code let you do things that are far more expensive or awkward on the JVM. Writing a significant amount of functionality that does no heap allocation is more feasible on the CLR than JVM. Native interop is an order of magnitude easier. The CLR is generally much faster to start up; Java terminal apps don't suit interactive use. The library linking story is much more pleasant too, with a single dynamically linked executable referencing GAC-installed assemblies, rather than stringing together enormously long class paths.
> it has a feature superset.
True, although the most relevant difference is value types, which Java is getting, too. As to the rest, it's not about the number of features, but the quality of implementation. HotSpot's JIT and GCs are simply years ahead of the CLR, and HotSpot's next-gen JIT, Graal, is another tremendous leap forward.
> The CLR is generally much faster to start up
Compared to HotSpot, yes (but, like you said, there are many JVMs out there), although Java 9's JIT caching will change that.
> The library linking story is much more pleasant too, with a single dynamically linked executable referencing GAC-installed assemblies, rather than stringing together enormously long class paths.
This, too, is no longer the case in Java 9, but the difference in the other direction is much more relevant: the JVM's agent capabilities (both Java and native agents) are one of the things that give the JVM its power. The ability to easily transform code as it's loaded (or after its loaded) packs a lot of oomph.
In general I'd say that the JVM offers fewer abstractions, but more powerful ones and it offers less opportunities for hand-tuned optimizations and more for automatic optimizations. In the end, HotSpot is simply much more advanced internally. The CLR is like a car with more buttons, but HotSpot is the car with the better engine. HotSpot has always opted for constant change that's hidden from the user, while the CLR has been adding more and more user-accessible features.
The work being done on Graal/Truffle is so far ahead of anything anyone else is doing, that it will put HotSpot's JIT beyond the reach of any other technology for years to come. It seems to me that the CLR might even stop competing and C# might switch to AOT compilation, with VB possibly being abandoned. Some of the latest moves by MS seem to hint in that direction (RyuJIT was already done or nearly so).
Graal/Truffle looks lot like DLR. Are they similiar ?
I assume their purpose is similar, but they are really a framework for building very sophisticated JITs -- much more than HotSpot's current optimizing JIT, which is state-of-the-art -- with user-controlled code generation. The CLR has a very primitive JIT to begin with. So while the purpose might be similar, Graal/Truffle represent the future of JITs, while DLR is just a framework that helps implementing dynamic languages for the CLR.
1 reply →
Do you have a blog post or some external site that you could link to for more information about the JVM vs. CLR? It'd be much appreciated
That's a really helpful review of reasons to consider CLR. Thanks.