In fact, the opposite. I'm trying to have a really...
# getting-startedb
benleggiero
03/21/2017, 3:47 PMIn fact, the opposite. I'm trying to have a really strong reason to always have them match. So, when I distribute a JAR for 64-bit machines, I want all integers and fractions to be 64-bit. On the other hand, when I distribute the 32-bit, I want all integers and fractions to be 32-bit. I don't like this mixed approach.
d
dalexander
03/21/2017, 3:51 PM…But why do you want to do that? That sounds like asking for random problems to crop up.
b
benleggiero
03/21/2017, 3:53 PMThis is how Apple does it with Foundation's
NSIntegerIntCGFloatbenleggiero
03/21/2017, 3:53 PMThat leads to a more stable and faster application, since the number is already in a form the processor can understand
d
dalexander
03/21/2017, 3:56 PMThat… is not true. Ints should be as fast or faster on an 64 bit system because of the reduced pressure on the memory subsystem compared to longs, if the JIT thinks it will be faster it can easily translate the items into longs at runtime but I find that very unlikely to be the case. The same is true with floats for similar reasons, even though as I mentioned elsewhere the x86 FPU operates on an 80-bit object.
➕ 1
b
benleggiero
03/21/2017, 4:02 PMI'm not concerned about speed with integers so much (except that 64-bit on a 32-bit platform has extra steps) as I am with floating-point performance and memory usage (32-bit platforms being limited to 4GB).
Another topic is "why don't we have
Float80d
dalexander
03/21/2017, 4:05 PMBecause the JVM doesn’t support a Float80, and such a construct would only be relevant a subset of all processors? For floating point performance you always want to use floats unless you need the extra precision a double provides. The size of the ALU (it. 32-bit vs. 64-but processor) has nothing to do with the size of the FPU.
➕ 1
dalexander
03/21/2017, 4:07 PMThe way the JVM defines floating point behavior is fairly specific in that it tries not to use things which are platform-dependent. So if you write some C++ code targeting an x86 processor that does floating point math you might end up with slightly different results depending on if your intermediate values are stored back to registers or stay in the FPU. As far as I know that shouldn’t happen with Java.
m
mattpeterson
03/21/2017, 4:15 PMEven in the Swift universe Float80 is not supported by all platforms, which would be anathema for Java and, by extension, Kotlin.
b
benleggiero
03/24/2017, 8:41 PMIf you want to use`Float` by default, and only
DoubleDouble