4 ms·

I'd be curious about why the Java benchmarks are so much better than the Kotlin ones. I could buy hotspot JVM optimizations making it better than, say, Rust. Bu

by lz400 5y ago

I'd be curious about why the Java benchmarks are so much better than the Kotlin ones. I could buy hotspot JVM optimizations making it better than, say, Rust. But shouldn't Kotlin be leveraging the same speed ups? The explanations could be: a) the bytecode generated by the Kotlin compiler is much worse and b) the benchmark Kotlin code is not as good or optimized as the Java one.

chrisseaton 5y ago
Java has the compiler in memory while running. Rust's compiler is a separate program so isn't in memory while it runs. That by itself is a lot of code.
- oriolid 5y ago
  Kotlin runs in JVM and should get the same benefits from live profiling and JIT compilation.
  - pjmlp 5y ago
    Like all guest languages it needs to generate additional boilerplate to pretend to be Java, and support its additional features not available out of the box in JVM bytecodes.
    - dtech 5y ago
      Kotlin should be close-to-identical* in terms of bytecode it immits for straightforward code like this, it's designed to very closely match Java capabilities, among others to make sure interop is very good. * Exception is supporting things like default methods on JVM 1.6 bytecode
      - pjmlp 5y ago
        Apparently that isn't the case. Additionally it is stuck on Java 8 view of the world, otherwise those .class files won't be usable on Android toolchain thanks Google.
        jontro 5y ago
        Looks like it supports generating class files up to java 16 https://kotlinlang.org/docs/compiler-reference.html#jvm-target-version https://kotlinlang.org/docs/compiler-reference.html#jvm-targ...
        pjmlp 5y ago
        Yeah, but it can't make use of JVM bytecodes without DEX counterparts, nor JVM abilities unknown to ART.
        dtech 5y ago
        Incorrect, the Kotlin compiler allows you to specify the target JVM level, it can generate JVM 1.6 bytecode (for android) up to 16. I know for a fact it uses different bytecode features if the level is >= 1.8, not sure how smart it is above that.
        pjmlp 5y ago
        It can only generate bytecode features that ART understands, and D8 is able to convert into DEX, thus is the price of Android marriage. Going forward while for Java code there is no worry about using SIMD, JNI replacement, value types, Kotlin code will need to make use of KMM for code that is supposed to target both JVM and Android.
        dtech 5y ago
        Are you so dense that you cannot understand that the Kotlin compiler can do gasp different things depending on different settings? It can do stuff android doesn't support if you set the bytecode target level to > 1.8 It's like using modern Javascript features but providing a polyfill for older browsers.
        pjmlp 5y ago
        Which produces libraries that are worthless to be consumed from Android without recompiling. Also stuff like value classes will have different semantics in memory consumption and performance across targets. Maybe some learning required?
  - chrisseaton 5y ago
    Oh I replied to the wrong comment - I was commenting on why it used more memory than Rust.
  - lallysingh 5y ago
    Optimizers can be finicky; kotlin and Java are going to generate different bytecode. The optimiser's been optimized for Java, and those differences will matter
throwaway4good 5y ago
For comparison: https://github.com/LesnyRumcajs/grpc_bench/blob/master/kotlin_grpc_bench/src/main/kotlin/io/grpc/examples/helloworld/HelloWorldServer.kt https://github.com/LesnyRumcajs/grpc_bench/blob/master/kotli... https://github.com/LesnyRumcajs/grpc_bench/blob/master/java_grpc_sgc_bench/src/main/java/io/grpc/examples/helloworld/HelloWorldServer.java https://github.com/LesnyRumcajs/grpc_bench/blob/master/java_... Looking at the build files, different versions of the libraries appears to be used. The Java implementation is configurable but defaults to something called "direct executor". Maybe that explains the difference.
- jontro 5y ago
  Also the kotlin example is using coroutines
  - lokedhs 5y ago
    Coroutines in Kotlin can be convenient, but they are overall about 20% slower than non-suspending code. I didn't spend too much time investigating the cause, but I believe it's because of the extra object that is passed along in all method calls. In my case, I have a programming language interpreter implemented in Kotlin, and as an experiment I made the entire interpreter using suspending calls so that I could call asynchronous functions, and my performance tests dropped by about 20%.
    - tom_mellior 5y ago
      As I understand it, Kotlin coroutines generate what is known as irreducible control flow. This means that loops have more than one entry point, or equivalently, there are loops that have a goto jumping into the body from the outside. (Java the language and I believe also Kotlin the language don't have goto, but the Java bytecode does.) Irreducible loops make many optimizations much more complex. Bytecode generated by javac never contains irreducible loops, and since bytecode generated by javac is the number 1 use case targeted by JVM JIT compilers, they probably just don't bother trying to be that smart about irreducibility.

by lz400 5y ago

chrisseaton 5y ago

Java has the compiler in memory while running. Rust's compiler is a separate program so isn't in memory while it runs. That by itself is a lot of code.

oriolid 5y ago
Kotlin runs in JVM and should get the same benefits from live profiling and JIT compilation.
- pjmlp 5y ago
  Like all guest languages it needs to generate additional boilerplate to pretend to be Java, and support its additional features not available out of the box in JVM bytecodes.
  - dtech 5y ago
    Kotlin should be close-to-identical* in terms of bytecode it immits for straightforward code like this, it's designed to very closely match Java capabilities, among others to make sure interop is very good. * Exception is supporting things like default methods on JVM 1.6 bytecode
    - pjmlp 5y ago
      Apparently that isn't the case. Additionally it is stuck on Java 8 view of the world, otherwise those .class files won't be usable on Android toolchain thanks Google.
      - jontro 5y ago
        Looks like it supports generating class files up to java 16 https://kotlinlang.org/docs/compiler-reference.html#jvm-target-version https://kotlinlang.org/docs/compiler-reference.html#jvm-targ...
        pjmlp 5y ago
        Yeah, but it can't make use of JVM bytecodes without DEX counterparts, nor JVM abilities unknown to ART.
      - dtech 5y ago
        Incorrect, the Kotlin compiler allows you to specify the target JVM level, it can generate JVM 1.6 bytecode (for android) up to 16. I know for a fact it uses different bytecode features if the level is >= 1.8, not sure how smart it is above that.
        pjmlp 5y ago
        It can only generate bytecode features that ART understands, and D8 is able to convert into DEX, thus is the price of Android marriage. Going forward while for Java code there is no worry about using SIMD, JNI replacement, value types, Kotlin code will need to make use of KMM for code that is supposed to target both JVM and Android.
        dtech 5y ago
        Are you so dense that you cannot understand that the Kotlin compiler can do gasp different things depending on different settings? It can do stuff android doesn't support if you set the bytecode target level to > 1.8 It's like using modern Javascript features but providing a polyfill for older browsers.
        pjmlp 5y ago
        Which produces libraries that are worthless to be consumed from Android without recompiling. Also stuff like value classes will have different semantics in memory consumption and performance across targets. Maybe some learning required?
- chrisseaton 5y ago
  Oh I replied to the wrong comment - I was commenting on why it used more memory than Rust.
- lallysingh 5y ago
  Optimizers can be finicky; kotlin and Java are going to generate different bytecode. The optimiser's been optimized for Java, and those differences will matter

throwaway4good 5y ago

For comparison: https://github.com/LesnyRumcajs/grpc_bench/blob/master/kotlin_grpc_bench/src/main/kotlin/io/grpc/examples/helloworld/HelloWorldServer.kt https://github.com/LesnyRumcajs/grpc_bench/blob/master/kotli... https://github.com/LesnyRumcajs/grpc_bench/blob/master/java_grpc_sgc_bench/src/main/java/io/grpc/examples/helloworld/HelloWorldServer.java https://github.com/LesnyRumcajs/grpc_bench/blob/master/java_... Looking at the build files, different versions of the libraries appears to be used. The Java implementation is configurable but defaults to something called "direct executor". Maybe that explains the difference.

jontro 5y ago
Also the kotlin example is using coroutines
- lokedhs 5y ago
  Coroutines in Kotlin can be convenient, but they are overall about 20% slower than non-suspending code. I didn't spend too much time investigating the cause, but I believe it's because of the extra object that is passed along in all method calls. In my case, I have a programming language interpreter implemented in Kotlin, and as an experiment I made the entire interpreter using suspending calls so that I could call asynchronous functions, and my performance tests dropped by about 20%.
  - tom_mellior 5y ago
    As I understand it, Kotlin coroutines generate what is known as irreducible control flow. This means that loops have more than one entry point, or equivalently, there are loops that have a goto jumping into the body from the outside. (Java the language and I believe also Kotlin the language don't have goto, but the Java bytecode does.) Irreducible loops make many optimizations much more complex. Bytecode generated by javac never contains irreducible loops, and since bytecode generated by javac is the number 1 use case targeted by JVM JIT compilers, they probably just don't bother trying to be that smart about irreducibility.