4 ms·
It’s also what we do when incrementing a counter, if it’s a very big counter. Operations like that don’t have a physical meaning, but can happen in things like
by skybrian 2y ago
It’s also what we do when incrementing a counter, if it’s a very big counter. Operations like that don’t have a physical meaning, but can happen in things like random number generators where it’s a way of mixing the bits. Or maybe allocating unique ids, if you started from a random number.
- bee_rider 2y agoOf course it is just an example so we shouldn’t nitpick you too much, but that sounds more like a job for an integer.
- skybrian 2y agoYes, absolutely. Though in JavaScript we often make do with the safe integer range. (I don’t know how fast BigInt is for 64 bit integers.)
- bee_rider 2y agoI don’t know JavaScript so I’m sure to shoot my own foot here, but surely a BigInt who’s value can fit in 64 bits is just a normal 64 bit int (from hardware) with some extra bookkeeping around it on most platforms, right?
- IainIreland 2y agoI can't speak for any other engines, but in SpiderMonkey a BigInt is a GC-managed object with a one-word header containing the sign bit, the length, and some GC bookkeeping bits, along with a second word that is either a single inline 64-bit digit, or a pointer to an array of 64-bit digits. So the memory overhead of a BigInt that fits in 64 bits is "only" 2x, but doing math with BigInt requires more work than a native integer because it needs to handle larger numbers, manually manage sign bits, and so on. (https://searchfox.org/mozilla-central/source/js/src/vm/BigIntType.h#49-464 https://searchfox.org/mozilla-central/source/js/src/vm/BigIn...)
- aardvark179 2y agoIf all you’ve got is JS then every problem looks like a double.