5 ms·

You’re going to love Kotlin, it really is a fantastic pragmatic language. You’re also likely to discover that while C# the language is amazing, the CLR runtime

by dpratt 5y ago

You’re going to love Kotlin, it really is a fantastic pragmatic language. You’re also likely to discover that while C# the language is amazing, the CLR runtime looks frankly minor league when compared to the JVM.

creato 5y ago
> the CLR runtime looks frankly minor league when compared to the JVM. This is comically backwards from my experience. I often see near-native optimized performance on C#/CLR, where I see similar code (SIMD friendly loops) literally hundreds if not thousands of times slower than it should be in Java.
- jpgvm 5y ago
  See my longer reply but I think this basically comes down to it being much easier to write fast C#. Generally if you are experienced enough with Java you can make it do what you want and get to the same performance (or higher) with Java but it's definitely not as easy and I do think this is a serious downside to Java.
  - deleted 5y ago
    [deleted]
- pjmlp 5y ago
  Which Java? OpenJDK, GraalVM, Open J9, Aicas, PTC, microEJ, Azul, Amazon,....
- _old_dude_ 5y ago
  Very true, Java was late in the game in term of SIMD loop optimizations compared to C#. Oracle engineers did the first implementation for Java 7, more recently it's mostly contributions from Intel, AMD and ARM [1]. [1] https://cr.openjdk.java.net/~vlivanov/talks/2019_CodeOne_MTE_Vectors.pdf https://cr.openjdk.java.net/~vlivanov/talks/2019_CodeOne_MTE...
unbanned 5y ago
Elaborate please
jbjbjbjb 5y ago
What is better in the JVM?
- jpgvm 5y ago
  I think both have different pros. Java has higher peak JIT performance though after Rosalyn was introduced C# has made strides at closing that gap on many metrics. GC algorithms are more advanced, namely ZGC and Shenandoah. I would elaborate but I don't want to turn this post into an actual essay. JVM is more configurable. This is a double edged sword, it heavily favors users that have spent the time to really understand the platform but it has created a reputation of the JVM being hard to operate. JVM class loaders and the new(ish) Jigzaw module system are very powerful, especially for shipping customized/cut-down JVM + stdlib when you need to do distribution. JVM has better portability. .NET Core has obviously changed the game but other platforms are still treated second class to Windows in many ways. GraalVM is reviving the guest language ecosystem of the JVM. Clojure, Scala and Kotlin have all remained reasonably strong but there was a dark period there for Jython/JRuby and friends. GraalVM is changing the tide here and I have already been able to leverage this over Nashorn to embed essentially native speed JS code into one of my Java programs. CLR has better primitive types, JVM's project Vahalla may resolve this. The CLR/.NET tends to introduce features at a quicker pace than the JVM/Java, this I feel is CLR's double edged sword. Async/await being the key example. It's been in the CLR for what feels like forever now vs JVM which is only now just getting close to landing Loom. However I feel like Loom is an infinitely better solution to the problem that leverages the unique advantages of JIT compiled VM languages that rely on relatively little unmanaged code. The experience on the CLR is much more integrated assuming you are on the well trodden path. i.e VS + Windows 10. MSIL is much much more pleasant than JVM bytecode in my experience and the community developed tooling for working with it is great. Optimizing programs on CLR is easier than JVM, it takes comparatively less effort to write allocation free code and get great memory layout using primitive arrays etc for high performance code. CLR interacts better with native code. JNI is poor in comparison. Project Panama could make this better on the JVM side. This is by no means a complete list of ways the two differ, this is just my experiences having written a decent chunk of code for both. FWIW I prefer the JVM but if I am forced not to use the JVM the CLR is the very next thing I propose.

by dpratt 5y ago

creato 5y ago

> the CLR runtime looks frankly minor league when compared to the JVM. This is comically backwards from my experience. I often see near-native optimized performance on C#/CLR, where I see similar code (SIMD friendly loops) literally hundreds if not thousands of times slower than it should be in Java.

jpgvm 5y ago
See my longer reply but I think this basically comes down to it being much easier to write fast C#. Generally if you are experienced enough with Java you can make it do what you want and get to the same performance (or higher) with Java but it's definitely not as easy and I do think this is a serious downside to Java.
- deleted 5y ago
  [deleted]
pjmlp 5y ago
Which Java? OpenJDK, GraalVM, Open J9, Aicas, PTC, microEJ, Azul, Amazon,....
_old_dude_ 5y ago
Very true, Java was late in the game in term of SIMD loop optimizations compared to C#. Oracle engineers did the first implementation for Java 7, more recently it's mostly contributions from Intel, AMD and ARM [1]. [1] https://cr.openjdk.java.net/~vlivanov/talks/2019_CodeOne_MTE_Vectors.pdf https://cr.openjdk.java.net/~vlivanov/talks/2019_CodeOne_MTE...

unbanned 5y ago

Elaborate please

jbjbjbjb 5y ago

What is better in the JVM?

jpgvm 5y ago
I think both have different pros. Java has higher peak JIT performance though after Rosalyn was introduced C# has made strides at closing that gap on many metrics. GC algorithms are more advanced, namely ZGC and Shenandoah. I would elaborate but I don't want to turn this post into an actual essay. JVM is more configurable. This is a double edged sword, it heavily favors users that have spent the time to really understand the platform but it has created a reputation of the JVM being hard to operate. JVM class loaders and the new(ish) Jigzaw module system are very powerful, especially for shipping customized/cut-down JVM + stdlib when you need to do distribution. JVM has better portability. .NET Core has obviously changed the game but other platforms are still treated second class to Windows in many ways. GraalVM is reviving the guest language ecosystem of the JVM. Clojure, Scala and Kotlin have all remained reasonably strong but there was a dark period there for Jython/JRuby and friends. GraalVM is changing the tide here and I have already been able to leverage this over Nashorn to embed essentially native speed JS code into one of my Java programs. CLR has better primitive types, JVM's project Vahalla may resolve this. The CLR/.NET tends to introduce features at a quicker pace than the JVM/Java, this I feel is CLR's double edged sword. Async/await being the key example. It's been in the CLR for what feels like forever now vs JVM which is only now just getting close to landing Loom. However I feel like Loom is an infinitely better solution to the problem that leverages the unique advantages of JIT compiled VM languages that rely on relatively little unmanaged code. The experience on the CLR is much more integrated assuming you are on the well trodden path. i.e VS + Windows 10. MSIL is much much more pleasant than JVM bytecode in my experience and the community developed tooling for working with it is great. Optimizing programs on CLR is easier than JVM, it takes comparatively less effort to write allocation free code and get great memory layout using primitive arrays etc for high performance code. CLR interacts better with native code. JNI is poor in comparison. Project Panama could make this better on the JVM side. This is by no means a complete list of ways the two differ, this is just my experiences having written a decent chunk of code for both. FWIW I prefer the JVM but if I am forced not to use the JVM the CLR is the very next thing I propose.