3 ms·

I've hit the 2147483647 limit of indices occasionally in VFX/Graphics with large datasets: memory efficiency was also important, so 32-bit was a necessity (rand

by berkut 5y ago

I've hit the 2147483647 limit of indices occasionally in VFX/Graphics with large datasets: memory efficiency was also important, so 32-bit was a necessity (random access is required, so can't dynamically pack), so I tend to use unsigned these days (uint32_t) within arrays, but native 64-bit lengths (normally size_t) as standard local variables, and I normally go with unsigned there as well. Several APIs in the VFX arena (Pixar OpenSubD, Pixar USD, and Foundry's Katana GeoLib API) all use signed ints for indices which I've occasionally argued against, with the response being "Google's coding standard says don't use them".

kstenerud 5y ago
Yup, and that's a case of an API not aging well. But even in that case, switching to unsigned is only kicking the can down the road, not solving the problem. You'd get another year or two and then hit the 4294967295 limit. As for 64-bit values, unless you can foresee requiring > 8 quintillion, unsigned isn't buying you anything.
- mjevans 5y ago
  Resource consumption does matter though. For example CPU caches or the quantity of RAM within a system. If their workset does fit within 32 bits of index the intentional design choice very likely correlates to a measurable improvement in speed due to cache locality and system resource utilization.
  - kstenerud 5y ago
    Indeed it does matter! As I said this is an example of an API that hasn't aged well (when they devised it, they probably didn't envision this happening). There are a number of ways to handle this: - Use unsigned 32-bit (gives you a little bit more runway, but you'll still hit the end hard) - Use 64-bit values (ends your problem once and for all, but costs double the memory so now you have a new problem) - Use 40-bit values (Gives you a lot more runway, but costs CPU)
virtualritz 5y ago
TBH I think this is pure laziness. I looked at OpenSubdiv extensively. There are no good reasons to use signed in the cases I opened the ticket for and making sure the code inside the lib does the right thing with unsigned arithmetic is trivial. But someone still needs to do that and writing that "Google (essentially) says you don't need to" in their style guide is much less work. ;-)

by berkut 5y ago

kstenerud 5y ago

Yup, and that's a case of an API not aging well. But even in that case, switching to unsigned is only kicking the can down the road, not solving the problem. You'd get another year or two and then hit the 4294967295 limit. As for 64-bit values, unless you can foresee requiring > 8 quintillion, unsigned isn't buying you anything.

mjevans 5y ago
Resource consumption does matter though. For example CPU caches or the quantity of RAM within a system. If their workset does fit within 32 bits of index the intentional design choice very likely correlates to a measurable improvement in speed due to cache locality and system resource utilization.
- kstenerud 5y ago
  Indeed it does matter! As I said this is an example of an API that hasn't aged well (when they devised it, they probably didn't envision this happening). There are a number of ways to handle this: - Use unsigned 32-bit (gives you a little bit more runway, but you'll still hit the end hard) - Use 64-bit values (ends your problem once and for all, but costs double the memory so now you have a new problem) - Use 40-bit values (Gives you a lot more runway, but costs CPU)

virtualritz 5y ago

TBH I think this is pure laziness. I looked at OpenSubdiv extensively. There are no good reasons to use signed in the cases I opened the ticket for and making sure the code inside the lib does the right thing with unsigned arithmetic is trivial. But someone still needs to do that and writing that "Google (essentially) says you don't need to" in their style guide is much less work. ;-)