3 ms·

What do you do with a 128bit integer? I already kind of consider 64 bit to be infinite. Maybe some performance optimization hack where you can use a big intege

What do you do with a 128bit integer? I already kind of consider 64 bit to be infinite. Maybe some performance optimization hack where you can use a big integer instead of a float for faster math? Skip right past 64bit unix time and give yourself a lot of breathing room?

loeg 3y ago
It's a nice scalar representation of a UUID, for example. Also it makes a nice internal state for a fast 64-bit PRNG (e.g., any 128/64-bit LCG/MCG, such as pcg64).
- ainar-g 3y ago
  IPv6, too. (Unless you also need interface IDs for link-local addresses.)
jeroenhd 3y ago
I have used 128 bit (and even 256 bit) numbers during Advent of Code when I was too lazy to optimize my algorithm and found that the puzzle input didn't exceed the 64 bit space by enough to look into arbitrary sized integers or better algorithmic solutions. There are also some data formats that are 128 bit, like others mentioned.
pclmulqdq 3y ago
Cryptography, UUIDs and some other hashing things, certain kinds of counters. Also, 2^64 is only about 10^19, so if you happen to have 20 exabytes that you want to byte-address, you can't do it with 64-bit pointers.
breckognize 3y ago
When I worked on S3, I was briefly responsible for reporting waste in the system. The basic equation was [Total Capacity of Hard Drives] - [# of bytes customers are paying for] * [Replication factor] = Waste One week as I was preparing the report, it was clear something had gone haywire. Waste was roughly equal to total capacity. So either we'd lost all of our customers overnight, or there was a bug. Turns out the legacy billing system was using a long to count # of paid bytes and this had overflowed. So it does happen.
- sanxiyn 3y ago
  u64 overflows at 16 exabytes, so it sounds plausible. Cool story.
- tialaramex 3y ago
  This is a classic example of why overflow instead of being defined (as some people want) as wrapping (since that's what the CPU naturally does for basic arithmetic), it should be an error, and if you didn't handle it (and in many cases you hadn't even realised it could happen so why would you?) thus fatal. If the report runs and says something like "Fatal: Overflow while multiplying customer_space * repl_factor. Consider floating point numbers or a larger integer type" - you'd go "Oops" fix the bug and run it again.
cryptonector 3y ago
64 bits are barely enough to do financial calculations ranging from fractional pennies to the sum of all assets and liabilities in the world.
ooterness 3y ago
I needed 128-bit and 256-bit integers on an embedded project recently. In short, it was for fixed-point digital signal processing. The raw input and output samples were int64_t. We needed to add, subtract, multiply, and accumulate these to do filtering and linear regression with no loss of precision. Conventional bigintegers weren't an option because the target application doesn't allow heap allocation. So we rolled our own [1] stack-allocated, fixed-width big integer class. [1] https://github.com/the-aerospace-corporation/satcat5/blob/main/src/cpp/satcat5/wide_integer.h https://github.com/the-aerospace-corporation/satcat5/blob/ma...
- fluoridation 3y ago
  Was there a reason not to use boost::multiprecision?
  - ooterness 3y ago
    In this case, the target platform has 256 kiB of RAM, no hardware floating point, and no operating system. I could be wrong, but Boost did not look like a good fit.
codeflo 3y ago
Depending on the application, going for floats can be a huge mistake: you only exact integer math up to 2^52 or 10^15. That’s hardly infinite, and insufficient for many applications.
fluoridation 3y ago
If you need to do multiplication of 64-bit values of unknown ranges you have no choice but to store the result in 128 bits, even if it's only an intermediate result.
saagarjha 3y ago
128-bit atomics are a common usecase.

loeg 3y ago

It's a nice scalar representation of a UUID, for example. Also it makes a nice internal state for a fast 64-bit PRNG (e.g., any 128/64-bit LCG/MCG, such as pcg64).

ainar-g 3y ago
IPv6, too. (Unless you also need interface IDs for link-local addresses.)

jeroenhd 3y ago

I have used 128 bit (and even 256 bit) numbers during Advent of Code when I was too lazy to optimize my algorithm and found that the puzzle input didn't exceed the 64 bit space by enough to look into arbitrary sized integers or better algorithmic solutions. There are also some data formats that are 128 bit, like others mentioned.

pclmulqdq 3y ago

Cryptography, UUIDs and some other hashing things, certain kinds of counters. Also, 2^64 is only about 10^19, so if you happen to have 20 exabytes that you want to byte-address, you can't do it with 64-bit pointers.

breckognize 3y ago

When I worked on S3, I was briefly responsible for reporting waste in the system. The basic equation was [Total Capacity of Hard Drives] - [# of bytes customers are paying for] * [Replication factor] = Waste One week as I was preparing the report, it was clear something had gone haywire. Waste was roughly equal to total capacity. So either we'd lost all of our customers overnight, or there was a bug. Turns out the legacy billing system was using a long to count # of paid bytes and this had overflowed. So it does happen.

sanxiyn 3y ago
u64 overflows at 16 exabytes, so it sounds plausible. Cool story.
tialaramex 3y ago
This is a classic example of why overflow instead of being defined (as some people want) as wrapping (since that's what the CPU naturally does for basic arithmetic), it should be an error, and if you didn't handle it (and in many cases you hadn't even realised it could happen so why would you?) thus fatal. If the report runs and says something like "Fatal: Overflow while multiplying customer_space * repl_factor. Consider floating point numbers or a larger integer type" - you'd go "Oops" fix the bug and run it again.

cryptonector 3y ago

64 bits are barely enough to do financial calculations ranging from fractional pennies to the sum of all assets and liabilities in the world.

ooterness 3y ago

I needed 128-bit and 256-bit integers on an embedded project recently. In short, it was for fixed-point digital signal processing. The raw input and output samples were int64_t. We needed to add, subtract, multiply, and accumulate these to do filtering and linear regression with no loss of precision. Conventional bigintegers weren't an option because the target application doesn't allow heap allocation. So we rolled our own [1] stack-allocated, fixed-width big integer class. [1] https://github.com/the-aerospace-corporation/satcat5/blob/main/src/cpp/satcat5/wide_integer.h https://github.com/the-aerospace-corporation/satcat5/blob/ma...

fluoridation 3y ago
Was there a reason not to use boost::multiprecision?
- ooterness 3y ago
  In this case, the target platform has 256 kiB of RAM, no hardware floating point, and no operating system. I could be wrong, but Boost did not look like a good fit.

codeflo 3y ago

Depending on the application, going for floats can be a huge mistake: you only exact integer math up to 2^52 or 10^15. That’s hardly infinite, and insufficient for many applications.

fluoridation 3y ago

If you need to do multiplication of 64-bit values of unknown ranges you have no choice but to store the result in 128 bits, even if it's only an intermediate result.

saagarjha 3y ago

128-bit atomics are a common usecase.