Hacker News Reader

Comment by lz400 | Hacker News Reader

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.

View on HN

For comparison:

https://github.com/LesnyRumcajs/grpc_bench/blob/master/kotli...

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.

Also the kotlin example is using coroutines

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

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.

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.

Kotlin runs in JVM and should get the same benefits from live profiling and JIT compilation.

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.

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

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.

Looks like it supports generating class files up to java 16 https://kotlinlang.org/docs/compiler-reference.html#jvm-targ...

Yeah, but it can't make use of JVM bytecodes without DEX counterparts, nor JVM abilities unknown to ART.

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.

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.

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.

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?

Those are bytecode level related. You can't consume Java 16 libraries on Android either. It's not related to Kotlin at all.

You are either being deliberately obtuse or you genuinely have difficulty to understand that Java version, bytecode version, Kotlin compiler output and what bytecode Android supports are totally independent concepts.

Enjoy #KotlinFirst, I am out of this thread.

It is going to be fun to port back stuff to Java.

Oh I replied to the wrong comment - I was commenting on why it used more memory than Rust.

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

Reply on news.ycombinator.com