A bit silly questions: if precision is not an issue, what is the pros & cons to use Float over Double in JVM target platform?

• 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

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?

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.

all entries on the JVM operand stack and local variable array are 32-bit; long and double take up two consecutive slots

thanks @ephemient now I kind of recall the docs might refer to if you use short, might not helpful....

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

yeah, my case it does, lots of data 🙂

deep learning is in its own world, lots of their stuff works fine wtih fp16 (half-precision floats)

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.

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

@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)

Ah, thanks for the insight. That was what I roughly meant to remember but couldn't come up with a quick source of truth 🙂