https://kotlinlang.org logo
Join Slack
Powered by
is kotlin/native as stable as kotlin/jvm ?
# getting-started
k
is kotlin/native as stable as kotlin/jvm ?
👀 1
v
https://kotlinlang.org/docs/components-stability.html#current-stability-of-kotlin-components
Kotlin/JVM
Stable
1.0
Kotlin/Native Runtime
Beta
1.3
Kotlin/Native new memory manager
Beta
1.7.20
Kotlin/Native interop with C and Objective C
Beta
1.3
k
alright 🙂
as im wondering if i should use kotlin native or GRAALVM for LIBGDX
🤷 1
like, does kotlin native ONLY work with pure kotlin code or does it also allow java libs and java code?
h
By default, Kotlin native only supports Kotlin and with cinterop C code. Sure you can use some compilers to convert java/jvm bytecode to native code or use JNI.
c
You mentioned LibGDX so I'm assuming you're doing game development. Kotlin/JVM will be much faster than Kotlin/Native for that. GraalVM (to my knowledge) isn't a good fit for games.
k
alright
r
Kotlin/JVM will be much faster than Kotlin/Native [for game development]
That surprises me - I thought the JVM was a fairly major drawback to game level speeds?
c
Kotlin/Native is relatively new technology, the JVM has 30+ years of optimizations behind it. Kotlin still has GC etc in all platforms
Kotlin/Native is expected (but I haven't tested) to use a lot less RAM though.
r
OK, I'd imagined that if you were using it for glue code and a C / C++ framework of some kind underneath via a facade it would be a reasonable gaming solution, interesting to hear not.
c
Well of course if all you do in Kotlin is a scripting façade, that's a different story
My point is, any non-trivial algorithm is most likely faster in Kotlin/JVM than in Kotlin/Native, now if what you do is just a small script and the real work appears somewhere else, it's irrelevant to this discussion
the JVM has a reputation of being really slow but it's quite far from the truth. Of course though, everything depends on your use case.
a
The JVM reputation of being really slow is extremely outdated
r
I know, there's no VM that has ever had the engineering put into it that the JVM has. My understanding is that it excels at use cases where it can take its multiple runtime cycles through some code to decide how best to optimise it, and the odd 100ms garbage collection isn't a big issue, like HTTP servers; and is not so good for use cases that want fast startup or cannot cope with occasional brief pauses, like games and command line interfaces.
c
Except the renderer, games are not real-time, and a 100ms garbage collection pause is completely fine.
r
For instance a year ago for fun I tried "Hello world" in multiple formats; a rust compiled version took 3.588 ms to run, a kotlin/native version 6.868 ms, and a JVM one 74.629 ms.
v
There are not really pauses nowadays. There are quite some games written in Java and also command line tools. There are even use-cases where a Java program runs faster than an according native program. You can in each language write bad and slow code or good and fast code. But yeah, if you need every nanosecond and every bit of RAM, you probably have to use Assembler anyway. 😄
c
100ms is also a very extremely worst case. A game like Minecraft (which arguably is one of the most successful 3D games of all time, and is also known for not being well optimized) runs pretty well.
There are also multiple different GCs that have various performance requirements. Some of them are not even STW
You should also take into account the cost of parallelism. Coroutines are not a thing in C/C++, and you get a lot from having stuff like AI algorithms be heavily asynchronous which is hell to do in C++
r
I'm well aware of Minecraft, I've helped my son write extensions to it in Kotlin. But Minecraft's surely a paradigmatic example of how gameplay is more important than graphics in the success of a game, precisely because the graphics are objectively dramatically worse[1] than typical modern 3D games? Has anyone got an example of a top flight graphics & FPS dependent game that is deployed as JVM bytecode running on a JVM? I remember Il-2 Sturmovik used the JVM for the interface, but dropped down to C++ for the actual flying. I'd have thought if it were viable it would be an excellent idea, given Kotlin is streets ahead of C++ in terms of how much safety it gives you and how bug ridden games can be. [1] where worse means lower detailed, less lifelike - fine for its purposes, obv.
k
a
@Rob Elliot The JVM isn't the target for top game engines. Neither is Rust (yet) or Go, or Swift, or Dart, or a host of other languages. And most of them never will be. There is more than games in the world.
Everything has their place. But the JVM-is-so-slow shtick is getting old, and it was already getting old 15 years ago.
r
The conversation was explicitly about game development.
c
@Rob Elliot that's a bit unfair, Minecraft has editable terrain which basically no other game has.
r
What does that have to do with its graphics?
Minecraft's brilliant.
It's brilliant because of its game design - the complete freedom, the way that creation and playing happen via the same mechanisms, the way you can create games using it - it's ana stonishing bit of game design.
c
But yeah the main issue against using the JVM for 3d games now is that JNI has quite a high cost, so you're better off implementing the renderer in C/C++ and doing only high-level game logic on the JVM. Maybe Panama will help with that, maybe not. Anyway my point was between Kotlin/JVM and Kotlin/Native, not between Kotlin/JVM and C++.
@Rob Elliot you can't have highly detailed graphics and editable terrain. No matter the technology, it's just not a thing anyone managed to do
Also, not every game as AAA graphics
IMO the missing piece for the JVM for gaming is a first-party Vulkan (or similar) integration at the JVM-level, that doesn't have the downsides of JNI
It's definitely not a priority for Oracle though
u
I thought system's people tend to not like java, is not because it is slow, because it is not, but because of the performance unpredictability (gc)
v
The performance is not unpredictable. It is even extremely configurable
u
well, is it? you dont know when memory is going to be freed
atleast, that's what I heard from systems people about liking rust, that they need the predictability of c++ but in a nicer safer language
v
You might not know when, but you shouldn't care. I'm not familiar with all Garbage Collectors and choices maybe there is also some "more predictable" one. But there are serveral Garbage Collectors to choose from and with several options each if you really know what you do and need tweakage.
u
but this I believe is why spacex won't run java, they just cannot "risk" a gc
v
There is no risk in a proper GC o_O
u
okay I don' know, it's what I've heard, first there is jitting and stuff, sure you can solve that with AOT, but gc you cannot determine when it runs, and they need to know this memory is freed when this function returns/this other thing dealocates etc
v
As I said, they shouldn't care, that's what a GC is for. If they need to care, a language with GC is maybe not the right choice. But why should they care? And jitter I don't know, but can probably be eliminated by right choice of GC and its options.
u
but in system programming you do care, say self driving cars etc
v
Enumerating use-cases does not answer the question why they should care
u
because high performance applications care about predictability, they need to run the same way all the time, not sometimes randomly slower because of reasons, memory usage also differing etc, all hinges on how GC runs
v
Again, just because you have a GC does not mean anything is unpredictable or randomly slower
It's all a question of right choice. If you of course use the serial or default parallel GC, application will freeze during collection. But if you e. g. choose the Z GC, your application does not stop for more than 10 ms, which should be predictable enough.
u
Why is android itself mostly written in c++ then?
v
Ask the ones that implemented it. Besides, what you need on Android is a JVM implementation and that is Dalvik and and JVM implementations themselves are often written in non-Java language afair. Maybe also back then there were not as many GC choices, GC evolved pretty much in the last years. Z GC e. g. is stable as of Java 15 or something like that.
k
It's mainly JNI interop which is unavailable Eg, attempting to completely rewrite skia in java with GL bindings would be a collosal undertaking and would serverly hurt any expectations of native skia vs JVM skia
Also some things MUST be done in C/C++ that are otherwise impossible or impractical to do via JVM
Sust as for example, rewriting each C++ library used one by one to mostly pure java with little JNI bindings would just be a pain
Eg, C++ templates are practically impossible to do in Java genetics due to recursive instantiation and templated function resolution
Lifetime scopes are also non existent in java
Well Phantom References and Cleaner API are probably as close as we can get?
e
try (=)
(java)/`.use {}` (kotlin) are the the lifetime scope of resources
k
Yea but more of resources that exceed try/use scopes
Where manual disposal might become complicated or unwanted
166 Views
Open in Slack
PreviousNext
Powered by