Yes, SSE4 has some great -- and parallel as mentioned by both of us now -- bandwidth to throw at adds. FP still hurts if you have to cross the channel from the

Yes, SSE4 has some great -- and parallel as mentioned by both of us now -- bandwidth to throw at adds. FP still hurts if you have to cross the channel from the CPU and back again, and you do with common JS. Mobile is much worse. We disable SoftFP in SpiderMonkey by requiring modern-enough ARM, but Adobe can't in Tamarin (we both use the Nanojit back end). Really slow. Even real FP is not nearly the same as on SSE4.x. Indeed bignum is a bit int format, but since there's no finite precision limit, you can do as someone in jwz's blog comments suggested, and use milli-cents or whatever for currencies, and never suffer rounding. But you do have to scale. EDIT: so to be clear, I agree that bignums don't solve the .1 + .2 problem. IBM favored IEEE754r to handle that case, but no one could agree on the exact integration or worthiness of that finite-precision decimal format. Sam Tobin-Hochstadt's "fast, precise, rational: pick two" conclusion (cited by me in jwz's LJ in reply to someone pushing ratnums as all three) still holds. I think a case can be made for bignums on this two-out-of-three basis, but you'd still want double and you might even want decimal. This need for several numeric types led us to work on value types, so library authors can extend the language with new numeric types (including operator and literal support), and the TC39 committee is not the bottleneck and the one-size-fits-nothing-well decider.