I believe we should agree on what to compare judging if it’s good or bad.
My understanding is there [should be] no fundamental difference in performance of compiled C++ and K/N code, except ARC vs manual memory management. Please correct me if i’m wrong. So i have a feeling that it’s K/N compiler that seems to be the reason [and iperformance was not the goal at the moment]. JB also notes K/N is not ready for performance benchmarking at the moment. Just looking for the opportunity to enable optimizations [which i assume are turned off] to get early rough estimations.
1 Like
Unboxing works well, performance in pure numerical algoritms is exactly same in “clang -O3”, “konan -opt” and JVM versions, see test:
https://github.com/JetBrains/kotlin-native/tree/master/performance/numerical
Not very precise results, but - calculating 1000 digits of PI on my computer:
Clang: 7.0 seconds
Kotlin/Native: 7.0 seconds
Kotlin/JVM: 7.4 seconds
6 Likes
In my experience, the primitives of K/N work quite well but the memory management and the abstractions cost a lot right now, while profiling my K/N websocket server I found that K/N allocate/free very often making the use of abstractions (that use a lot of object) not efficient.
1 Like
Hi I’m interested in using Kotlin/Native in my job writing simulations. However I’ve found that for a simple model, Kotlin/Native is roughly 100x slower than when using the JVM. (This improved to only 50x slower with 1.3.61). I’m wondering two things:
- Would the developers of K/N be interested in my findings? I.e. is there a way I can contribute to K/N performance.
- How much run time performance can I expect in 1.4?
Thanks!
p.s. sorry if this is not the right thread for this 
My application depends heavily on boxed primitives (I have to, since I need to support complex numbers as well as bignums). I’m seeing 4 minute runtimes on something that takes 12 seconds on the JVM.
I haven’t spent too much time digging into precisely what it is that causes the slowness, but I expect it to be because of my heavy allocation/deallocation of objects. The performance of object allocation/deallocation is something that JVM does well enough that it’s hard for C++ to beat even under ideal circumstances (it’s where a compacting GC really shines).
However, I would like to know if this aspect is something the Kotlin native team is looking at improving. I understand it can never be as fast as the JVM, but it would be nice if it could eventually get within a few times slower.
1 Like
This implementation is not suitable for any native language. This LoC has a big performance issue :
next = ((head + 2L)…(head + delta + 1002L) step 2).toList()
It allocates a new memory heap (and afterwards releases it) for each iteration. This is very costly approach. I would say, JVM is so smart in memory management so that it reuses allocated memory for each iteration and hence a performance advantage. A native language has nothing like that.
Native does not automatically mean fast. You have to know about its natures. In this case, try to use stack memory or reuse heap memory will improve the performance.
Moreover, the filter, lambda approach could also has an issue. I would define a lambda function outside the loop or try with a procedural approach like if/else or normal function call.
1 Like
FYI I measured new data points with Kotlin 1.8 and Kotlin/Native is now much faster. Kotlin/JVM is still faster (as expected) but Kotlin/Native is only 32% slower than Kotlin/JVM with the original code shared by @tommot1985, with performance similar to Kotlin/JVM compiled with GraalVM native image. See GitHub - sdeleuze/prime-multiplatform: Compare Kotlin build time and performances on various platforms for more details.
2 Likes
Hi there, this is a very old thread 
I tested my code a month ago and it is much faster indeed. The “naive” implementation is still much slower in k/n than on JVM though.
1 Like