https://kotlinlang.org logo
Join Slack
Powered by
A bit silly questions: if precision is not an issu...
# getting-started
s
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
• 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
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
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
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
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
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
yeah, my case it does, lots of data 🙂
e
deep learning is in its own world, lots of their stuff works fine wtih fp16 (half-precision floats)
v
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
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
@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
Ah, thanks for the insight. That was what I roughly meant to remember but couldn't come up with a quick source of truth 🙂
Open in Slack
PreviousNext
Powered by