https://kotlinlang.org logo
Join Slack
Powered by
I'm looking for a fairly low level language (need ...
# kotlin-native
l
I'm looking for a fairly low level language (need access to platform APIs, building shared libraries, pointers), and I'm wondering if Kotlin/Native might suffice for that. I've ruled out C/C++ and Rust already because I'd prefer something else. Decent community support/libraries would also be nice. Thoughts?
v
What is the reason why C/C++/Rust are ruled out? Kotlin/Native can work for this purpose: • It has the ability to interact with native (C) libraries through cinterop • It can work with C pointers • It can export Kotlin code as shared libraries The community and library support is still very early days and not many libraries are availlable yet. While in theory you should be able to use any C library from your KN project, it will probably require getting familiar with cinterop and 
.def
files to create library bindings yourself.
l
I'm not a fan of those languages in general, and for Rust, especially the borrow checker. It's just a preference, but obviously I understand if there aren't any viable alternatives currently. Seems like Kotlin/Native would work for my use case, though. I'm just a little concerned about the future of it, as I've seen others mention the terrible performance
v
I guess it is still early days and only time will tell. I'm bullish on it and currently putting a lot of time in trying to get it to work for my own use cases.
l
Got it. Well, it's worth a try. Less obscure than the other options like D, at least.
l
The performance difference seems mainly associated with the runtime. K/N compiles to LLVM bitcode, same as C/C++/Rust, meaning aside from some bitcode optimizations, code that doesn’t need to trigger the GC should run about similar to C (backed up by my testing). There’s also of course the difference that K/N doesn’t compile to a ‘native’ (current CPU) target by default, unlike these languages, but that’s not useful in production anyways.
l
Hmm. Well, I'd imagine a lot of code would end up triggering the GC regardless. I wonder if there's any plans to improve the runtime performance then. Because 17x slower than C++ vs 4.3x for the JVM is pretty terrible.
l
Where did you get those numbers?
l
I've checked some others as well, though. It's a big difference
l
Kotlin 1.6 (in 2021) brought a large improvement in performance. I’d like to see the benchmarks with the latest versions of languages. I remember seeing Kotlin code being quite slow on the 1.5.x versions.
Looks like the C++ gets compiled with the native target and O3, which I’d argue is a bit misleading, since it doesn’t represent ‘production’ binaries, which rarely have either optimization applied.
l
There's this as well. Seems to be up to date. https://programming-language-benchmarks.vercel.app/kotlin-vs-cpp
l
Don’t get me wrong, for open source code, O3 and native target can greatly improve performance, but because native target can only build code that will run on the same model of CPU, and O3 optimizations often cause subtle bugs in large projects, few closed source projects would be built with either.
l
Oh yeah, fair point. But anything I'd write would be OSS anyway :)
l
Gentoo users often tout the performance improvements of native+O3 (they claim 2-3x performance benefit), but even Gentoo’s wiki recommends trying it first, and building ‘normally’ if you see weird issues.
l
I would be vary of O3 for sure.
l
I think it’s technically possible to tell the kotlin compiler to use both of those when running clang, but not sure how reliable that would be.
l
Being able to pass O2 and native might be nice if it's possible
l
I’d look into using freeCompilerArgs. Sounds like a cool weekend project (noting that you should never distribute a binary built with native target, since you can only guarantee it runs on the same CPU model).
l
Yes, of course. A public binary wouldn't use it
l
Complete guess based on vague memory: 
freeCompilerArgs += listOf("clang-flags", "-O3", "clang-flags", "target=native")
l
Cool! Will try it out
Well, those don't seem to be valid args for the kotlin compiler. I did some testing and it seems like native is still around 3x slower than the JVM. So, not ideal, but it's hard to gauge when it'll become an issue
v
It will depend on your use case as well. If your Kotlin code is mostly calling into other native libraries it won't matter that much. If you intend to write the performance-critical parts in Kotlin it's a different story. Which use case are you targetting and how are you benchmarking?
l
DLL injection into a game. It's not going to be performance critical, though. And seeing as the win32 api is accessible, it should be possible to hook into functions and stuff, right?
v
AFAIK there is no problem in accessing anything that can be accessed from C. (Calling functions, passing pointers, defining new functions and passing those as pointers to other C functions, etc)
l
Yeah, seems like it'd work fine
3 Views
Open in Slack
PreviousNext
Powered by