https://kotlinlang.org logo
#getting-started
Title
# getting-started
s

Steven Wang

11/01/2020, 11:40 PM
A bit silly questions: if precision is not an issue, what is the pros & cons to use Float over Double in JVM target platform?
v

Vampire

11/02/2020, 12:37 AM
• float takes half the ram of double • double is more precise than float • double has a wider range then float So if neither precision nor memory is a point it is probably mainly a question of the range you need
s

Steven Wang

11/02/2020, 12:42 AM
Thanks! I getting constrained by memory, but I remember read some docs in old days (I could be wrong --- I really could not remember the details and could not find out where I red it, that is many years ago ... ), that now days new processor designed with 64bit in mind, so float might actually make it slower ... or it says even float, internally java will store as double use 8 bytes?
v

Vampire

11/02/2020, 12:58 AM
That would be total news to me and actually it wouldn't make too much sense I'd say. But then, I'm not an expert regarding JVM internals. But either way, you shouldn't try to micro-optimize up-front. 1. Make your code work like it should (optimally with tests, that makes later steps much easier) 2. Make your code beautiful by refactoring 3. Optimize your code, but only where you actually measured a problem (performance, ram, ...) 80% of a programs runtime is spent in 20% of the code (rough average numbers), there is not much point in optimizing the other 80% of the code.
e

ephemient

11/02/2020, 2:27 AM
all entries on the JVM operand stack and local variable array are 32-bit; long and double take up two consecutive slots
JVM doesn't really operate on bytes
as far as speed is concerned, it'll depend on the architecture
classic x86 only has 80-bit floats, so for arithmetic it will be the same either way
with modern x86 (SSE2) and vectorization, you can perform twice as many single-precision float operations at once as double (each XMM register can hold either 4 floats or 2 doubles), but I don't think that matters to the JVM
some library routines (stuff like sin, exp, etc. probably) will be faster on floats because there's fewer iterations required to reach precision
s

Steven Wang

11/02/2020, 2:43 AM
thanks @ephemient now I kind of recall the docs might refer to if you use short, might not helpful....
got it, so means if precision is not concern, I definitely should switch to float, especially given now many deep learning library all operate on float
e

ephemient

11/02/2020, 2:44 AM
there's definitely cases where the reduced memory footprint of float helps, but unless you're working with lots of them, it probably doesn'tmatter
s

Steven Wang

11/02/2020, 2:44 AM
yeah, my case it does, lots of data 🙂
e

ephemient

11/02/2020, 2:45 AM
deep learning is in its own world, lots of their stuff works fine wtih fp16 (half-precision floats)
v

Vampire

11/02/2020, 8:45 AM
Yeah, I also remember some article or book from long ago that stated that byte and short are not worth it to save memory, as they are stored as integers internally. But I also don't remember what it was, if it is obsolete or right-away non-sense. https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html suggests you can save memory with them. But it is probably only significant in large arrays which is why those are mentioned. In other cases, the smaller types can be handy as range documentation per-se. Best is again, optimize if you have a problem and then just measure whether it makes a difference.
s

Steven Wang

11/02/2020, 11:04 AM
Thanks @Vampire. For my problem is mainly try to fit large data into memory, avoid have to use disk io. Yes, I agree with the principle that should optimize only if you have a problem
e

ephemient

11/02/2020, 6:39 PM
@Vampire in arrays and fields, bool/byte/short are stored packed, so it does save memory. in parameters and locals, they're int-sized, but it's hard to find cases where you'd have so many that it matters (maybe deep recursion)
(bools are packed as bytes, not as bits)
object layout is implementation-defined, not specified by JVMS, but it is true of openjdk and dalvik
v

Vampire

11/02/2020, 6:46 PM
Ah, thanks for the insight. That was what I roughly meant to remember but couldn't come up with a quick source of truth 🙂