Hacker News Reader

Comment by z3t4 | Hacker News Reader

JavaScript now has Bigint! (ES2020)

It's a bit strange that it got BigInt before Int64, for most applications 64 bits are plenty and arbitrary precision arithmetic is just needless overhead. Maybe a sufficiently smart JS engine could deduce that a BigInt can't exceed 2^64 and lower it to native 64 bit math, but that kind of magic is hard to rely on.

> It's a bit strange that it got BigInt before Int64

JavaScript has Int64?

Sorry, no it doesn't. I meant there should be an Int64 type and it probably should have been implemented before they dived into arbitrary precision integers.

I suppose the answer if you really care about performance is "just use WebAssembly" since that does have native 64 bit integers.

Why would it need a 64 bit int? How often do you go over 2*56 in Javascript?

As a pure quantity representing a real-world value, probably not very often, but just as a series of bits or a more abstract quantity like a memory address, it will often go above 2^56. Many algorithms and binary file encodings use 64 bit integers so interfacing with them in Javascript is hard.

All sorts of hash functions expect 64-bit intermediate values. Worse, these algorithms are liable to go haywire, and return very-not-randomized results if intermediate values are silently truncated to 56 bits (or magically become floating-point and thus lose their lower-order one bits) as happens when they're naively translated from C to JS.

Full 64 bit would very likely need to be boxed (heap allocated). I assume bigint is not boxed up to 40-something bits and instead stored as NaN[0]. Once you start boxing, the additional few instructions to handle things above 64 bit are probably not that important, so they may as well be generic.

[0] https://anniecherkaev.com/the-secret-life-of-nan

Interesting that there are 15*(2^47) unused values in this scheme in the range FFFF:xxx1:xxxx:xxxx - FFFF:xxxF:xxxx:xxxx. Could these be put to any practical use?

https://github.com/philihp/nanbox

You don't even need a Double, you can use a Float NaN to encode strings:

> IEEE 754 encodes 32-bit floating points with 1 bit for the sign, 8 bits for the exponent, and 23 bits for the number part (mantissa). (...)

> 23 bits isn't much space, but conveniently the max size of a Unicode codepoint is 0x10FFFF, making it a 22-bit charset. When you encode your strings in UTF-32, you're only going to be using 22 of those bits, so masking the top portion with the NaN signature makes all of your characters NaNs.

Not that strange considering Python effectively dropped Int64 support.

In Python 2.7 there was a distinction between when Python would use the "long int" vs the traditional Int64. This distinction was eventually entirely dropped in favor of all ints being "long ints". In case you are unfamiliar python implement ints internally as a list of digits. This is now true no matter the number of digits in the int.

What interesting about this is that there actually are edge cases where performance in Python 2.7 will be superior to Python 3. There's a nice foot note about this in "High Performance Python".

BigInt exists, but there is a chicken and egg issue.

It's slow, so nobody wants to use it and nobody uses it, so they don't see a need to optimize.

Reply on news.ycombinator.com