4 ms·

It's most likely for efficiency and performance reason. 64-bit doubles the storage requirement of 32-bit and would have impact on database's utilization of mem

by ww520 9y ago

It's most likely for efficiency and performance reason. 64-bit doubles the storage requirement of 32-bit and would have impact on database's utilization of memory, querying window size, cache, and storage. Edit: 32 bits worth of games played means about 4 billion games. 4 billion X 4 bytes for 32-bit = 16GB just for the 32-bit ID's. 64-bit ID's would need 32GB for the 4 billion games. I guess memory and storage weren't that cheap back then.

mikeash 9y ago
It sounds like it was client side, not server side. Most likely the iOS client was using Objective-C's NSInteger or Swift's Int, just because that's the default choice for most programmers working in that language, and they didn't think it through.
markcerqueira 9y ago
It also could've been just the person picking an int over a long. Is ints vs. longs the first place to look for optimizing efficiency/performance?
- cesarb 9y ago
  On a 32-bit system, a "long" is usually also 32 bits. On a non-Microsoft 64-bit system, a "long" is usually 64 bits. On both 32-bit and 64-bit systems (Microsoft or not), an "int" is usually 32 bits. If the issue happened only on 32-bit iPads, but not on 64-bit iPads, the programmer probably picked a "long", not an "int". Had the programmer picked an "int", the problem would also happen on 64-bit iPads.
  - e28eta 9y ago
    Our iOS app with Java backend was using long for database IDs on both ends. I was going through the ILP32->LP64 conversion process and when I realized we had a pretty serious discrepancy. I think it's a really easy mistake for the first developer to make (especially because they weren't a C/Obj-C programmer), and then the sort of thing that no one audits after that.
    - cesarb 9y ago
      Yeah, Java always uses 64 bits for "long", even on 32-bit systems. Which only adds to the confusion, since it's different from C and C++. (Another place where Java is confusingly different: "volatile" implies a memory barrier in Java, but not in C and C++.)

by ww520 9y ago

mikeash 9y ago

It sounds like it was client side, not server side. Most likely the iOS client was using Objective-C's NSInteger or Swift's Int, just because that's the default choice for most programmers working in that language, and they didn't think it through.

markcerqueira 9y ago

It also could've been just the person picking an int over a long. Is ints vs. longs the first place to look for optimizing efficiency/performance?

cesarb 9y ago
On a 32-bit system, a "long" is usually also 32 bits. On a non-Microsoft 64-bit system, a "long" is usually 64 bits. On both 32-bit and 64-bit systems (Microsoft or not), an "int" is usually 32 bits. If the issue happened only on 32-bit iPads, but not on 64-bit iPads, the programmer probably picked a "long", not an "int". Had the programmer picked an "int", the problem would also happen on 64-bit iPads.
- e28eta 9y ago
  Our iOS app with Java backend was using long for database IDs on both ends. I was going through the ILP32->LP64 conversion process and when I realized we had a pretty serious discrepancy. I think it's a really easy mistake for the first developer to make (especially because they weren't a C/Obj-C programmer), and then the sort of thing that no one audits after that.
  - cesarb 9y ago
    Yeah, Java always uses 64 bits for "long", even on 32-bit systems. Which only adds to the confusion, since it's different from C and C++. (Another place where Java is confusingly different: "volatile" implies a memory barrier in Java, but not in C and C++.)