https://kotlinlang.org logo
#gamedev
Title
# gamedev
s

sksk

06/17/2019, 6:35 PM
that's kinda sad to have to rely on C++ to have decent performance, if Valhalla ever get released, can we expect android's java to support it aswell ?
🤔 1
🙄 1
g

gildor

06/18/2019, 8:35 AM
Only for new versions of ART
s

sksk

06/22/2019, 7:47 PM
he went silent on this one, so i really really doubt they intend to support new features, android will never learn, they should have ditched JVM completly few years ago, apple teaching them a lesson again with swiftui and their focus on performance (struct and no class), same for metal and AR
😴 1
g

gildor

06/23/2019, 8:08 AM
Oh common. First of all they don't have JVM, they have own runtime, second, if you talking about dropping support for JVM Class format for some reason, it would make it completely incompatible with current code with no real reason. Second, assuming that it would l somehow dramatically improve performance by itself is at least naive assumption. Third, they focus on ART performance, which of course target wide range of common applications, and swift has classes for sure, if you talking about SwiftUI it super funny, because for example Compose not only avoid classes, but actually uses just compoasable functions that do not create tree of components for diffs (like shadow dom or SwiftUI structs), which, at least in theory is actually more performant approach than in SwiftUI And finally, If you think that ART is much slower and desperately broken by definition, you are not limited by ART, you can compile exactly the same code (even swift) to native binaries for ARM processors if for your use case it works better Also, because we are in gamedev channel I really don't understand all this ranting about ART or Swift performance, because most of game engines are written using C/C++ (at least core) and it's true for Android, iOS or desktop, again, just because for core components of high performant code you just should use lower level tools, same way as sometimes instead of C/C++ native development goes to assembly level, not because it's better in general, but because you want to optimize some very specific code, same way as sometimes JVM libraries use sun.misc.Unsafe
s

sksk

06/24/2019, 10:25 AM
Because i strive for performance by default, i hate when people overlook this problem and keep saying "but this is fine", no it is not fine, it is a major problem, because some people then depend on code that is slow and bloated by default, and that means you have to bloat your shit to workaround these issues, and then because my PC/Phone do more work than needed, and my battery dies quickly because people didn't realise a phone has limited power and battery, and therefore performance is EVEN MORE important, but it's fineeeeeeeeeeeeeee just get your charger with you all the time, and keep buffing your little phone About Compose, of course functions, because lack of ways to define cheap/free/efficient small value types Performance by default requieres good leadership, it requires people who constantly push other people to think about efficiency and performance, and to stop taking shortcuts like kotlin-native did with java(slow)/gradle(bloated/slow)/gc(slow)/concurrency(where are my cough coroutines), i can continue with many other examples but people will think i'm just a negative person, wich i'm not, i want stuff to be used by everyone, and i want people to care about performance, sure i can skip all that and use c++ right? easier than trying to point out and fix other people's mistakes And i don't pretend to be smart or anything, i wish i was more skilled to be able to contribute more
g

gildor

06/24/2019, 10:37 AM
About Compose, of course functions, because lack of ways to define cheap/free/efficient small value types
But it’s by definition better, not because you don’t have value types, but because you don’t need any kind useless shadow dom or other abstraction to keep information for diffs
Anyway, I don’t see any good arguments here, just some completely useless rant
s

sksk

06/24/2019, 10:38 AM
see, that is my point, people point out efficiency and performance issues and people keep saying, "useless" let's skip
g

gildor

06/24/2019, 10:39 AM
sure
I just trying to give some arguments, you just constantly say “slow, slower” with no proofs or comparasion, just ranting
Which is ridiculous as any attempt to measure performance using some theoretical assumptions without benchmarking
s

sksk

06/24/2019, 10:47 AM
JVM benchmark are broken by design because it needs warmup jit, wich is not something you want for real use case except for servers
g

gildor

06/24/2019, 10:50 AM
Benchark at least any real life use case
it’s not true that that has nothing to do with mobile for example
Android has such advanced things as cloud profiles
so yes, benchmarking is hard of course
much harder than complain about it with no real data, just using some imaginary assumptions