Draft: Use 128-bit floats instead of BigInts

[ptomato]

I read a paper on double-double precision arithmetic (i.e., using two Numbers to implement 128-bit floats with the same range as Number but twice the precision.) This precision would allow safe integers covering the entire epoch nanoseconds range that we support, as well as being precise enough for all the floating point calculations that we do in methods like Duration.p.total().

The paper is: Hida, Li, Bailey (2008). Library for double-double and quad-double arithmetic. Technical report, Lawrence Berkeley National Laboratory. https://www.davidhbailey.com/dhbpapers/qd.pdf

They published a C++ library at https://github.com/BL-highprecision/QD. It was a quick experiment to implement a subset of the operations in JS in lib/float128.ts. This allows us to get rid of both JSBI as well as the power-of-10-math-by-string-manipulation in lib/math.ts.

[ptomato]

This didn't have any obvious effect on performance, either good or bad.

Unfortunately it does make the default bundle bigger (by about +3k minified). Turns out JSBI is quite a small library when it's just a thin wrapper around BigInt! And if we ever got a build working where JSBI was compiled out when targeting new enough browsers, the increase in bundle size would get worse, because the default bundle would not even have JSBI in it.

But when transpiling down to ES5 it saves quite a lot of space (-31k minified). I doubt that's worth increasing everyone else's bundle size though.

So in the end I think my opinion is that we should not merge this, but I wanted to put it up for comments.

[justingrant]

If it doesn't make anything faster, and makes the bundle larger, then it doesn't seem worth doing, IMO.

[ptomato]

Yeah, my current thinking is that this is more of a curiosity that could be useful for implementations if they didn't want to use JS BigInt or compiler-dependent __int128 internally.