Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BigInt Shipping in Firefox

wingolog.org

Post reply on HN
Print view View original

161–170 of 172 posts

Re: BigInt Shipping in Firefox

#161

Post by wvenable »

fgonzag wrote: post #160
wvenable wrote: post #146

Earlier quoted context omitted.

https://www.npmjs.com/browse/depended/is-number

That's horrifying, I thought the whole isNumber thing was a joke. Do these guys assemble their application as hundreds (or thousands) of NPM packages containing single functions and then import them together? Because now I actually believe they are capable of it.

You might enjoy this as well: https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

And this: https://dev.to/leoat12/the-nodemodules-problem-29dc

Re: BigInt Shipping in Firefox

#162

Post by mschuetz »

lucb1e wrote: post #121
mschuetz wrote: post #109

Earlier quoted context omitted.

> I once wrote a replacement for the + operator in javascript because computers can't do proper addition (0.1+0.2!=0.3). That's normal floating point math behaviour and fine in most use cases. You can't fix this for add, sub, mul and div without serious performance implications. > Would it be that much slower, that it's an awful idea to do by default? Yes. Easily an order of magnitude slower, perhabs two. The fixed s…

I did some testing with pypy, which also works with arbitrarily large integers but iirc does JIT instead of interpretation (like cpython would do), so that should be similar to JS in V8 except that it has arbitrarily large integers. a = Math.pow(2, 1023) t = new Date().getTime() for (var i = 0; i vs a = pow(2, 1024) t = time.time() for i in range(int(1e7)): a += i print(time.time() - t) Both ran a bunch of times: pyp…

Rearanged your js sample a bit, now it runs in ~26ms (first time) and ~11ms (subsequent times) instead of ~220ms in the chrome developer console.

    {
        let a = Math.pow(2, 1023)
        let t = performance.now();
        let max = 1e7;
        for (let i = 0; i
Main problem was, that you should declare a with let.

That benchmark is a bit strange/flawed anyway. You're initializing a as pow(2, 1023), then adding numbers in the loop. But since a is already such a large double value, the result won't change. The numbers you add are too small to make a dent in the value of a, likely because a isn't an integer. It's a double with a limited precision for large integer values.

Re: BigInt Shipping in Firefox

#163

Post by cztomsik »

kevingadd wrote: post #138
vanderZwan wrote: post #132

Earlier quoted context omitted.

The implementations usually do (in the sense of optimizing them)

v8 only has 31-bit 'SMI' and not 32-bit ints, iirc.

on 64bit archs it is 32bit

https://github.com/thlorenz/v8-perf/blob/master/data-types.m...

Re: BigInt Shipping in Firefox

#164

Post by ghusbands »

cwzwarich wrote: post #130
wahern wrote: post #117

Earlier quoted context omitted.

JavaScript can't easily evolve past the optimization tricks used in the major implementations. They all heavily rely on NaN tagging which makes 64-bit value types problematic. For similar reasons the architecture of V8 in particular has effectively dictated the design of WebAssembly, especially regarding control flow constructs like goto and coroutines.

> For similar reasons the architecture of V8 in particular has effectively dictated the design of WebAssembly, especially regarding control flow constructs like goto and coroutines. The weirdness of WebAssembly with regards to control flow constructs is rooted in Emscripten's "relooper", which was developed in a naive manner ignoring previous (superior) research on irreducible control flow.

I have an interest in this - can you point at the earlier, superior research, please?

Re: BigInt Shipping in Firefox

#166

Post by [deleted] »

vaccarium wrote: post #131
lucb1e wrote: post #119

Earlier quoted context omitted.

How odd to notice that my brain really messed that number type up. I could swear Python has a type called (capitalized) Number and that this handles arbitrarily large numbers as well as decimals. Seems like that 'memory' is completely fictional.

Python does actually have an abstract type for numbers, and it is called Number: https://docs.python.org/3/library/numbers.html .

[deleted]

Re: BigInt Shipping in Firefox

#167

Post by cwzwarich »

saurik wrote: post #152
cwzwarich wrote: post #130

Earlier quoted context omitted.

> For similar reasons the architecture of V8 in particular has effectively dictated the design of WebAssembly, especially regarding control flow constructs like goto and coroutines. The weirdness of WebAssembly with regards to control flow constructs is rooted in Emscripten's "relooper", which was developed in a naive manner ignoring previous (superior) research on irreducible control flow.

I am pretty sure the reason for this is that alternative designs for control flow cannot be implemented in linear time; Java, for example, has experienced epic denial of service attack issues on their verifier design, where code of specific forms leads to quadratic verification time.

There are a few different performance issues with the Java bytecode verifier. Are you referring to this one?

https://pdfs.semanticscholar.org/7dd2/b5359ab507fec1b1223db6...

The cause of this is that the dataflow analysis performs nontrivial merging of dataflow facts, requiring a reanalysis. In the WebAssembly design there is no merging; any divergence of stack effects is an error.

There are other deeper issues with the Java design: bytecode subroutines, the fact that the Java subtype relation doesn't form a semilattice, and way in which Java bytecode models object initialization.

Re: BigInt Shipping in Firefox

#168

Post by mschuetz »

thaumasiotes wrote: post #116
lucb1e wrote: post #110

Earlier quoted context omitted.

I'm sorry but where did I insist upon proper addition? I'll annotate the parts of my post that might be mistaken for it: > a replacement for the + operator in javascript because computers can't do proper addition (0.1+0.2!=0.3). Just saying they can't do it (I edited this: first I said that JS doesn't do it properly, but I thought that was rather too narrow. I guess 'computers' is too broad again. Pick a name, you kn…

>> a replacement for the + operator in javascript because computers can't do proper addition (0.1+0.2!=0.3). > Just saying they can't do it (I edited this: first I said that JS doesn't do it properly, but I thought that was rather too narrow. I guess 'computers' is too broad again. Pick a name, you know what I mean) You can say it, but that won't make it true. They can do it, and they do do it. Your comment is so muc…

>> You can say it, but that won't make it true. They can do it, and they do do it. Your comment is so much nonsense. The algorithm computers use to add 0.1 and 0.2 is the same algorithm that you use, which is, unsurprisingly, why they produce correct results.

Are you aware of floating point math? That's what most languages, and almost all languages aimed at performance, use. It's defined in the IEEE 754 standard and supported on a hardware level in many devices.

Here is a listing of the result of 0.1 + 0.2 in various languages: https://0.30000000000000004.com/

As the URL already indicates, most languages, including C, Rust, C++, Java, Javascript, Clojure, FORTRAN, Python, etc. evaluate this to 0.30000000000000004. I'm fine with this, I need fast rather than precise math. But it's not "correct".

Re: BigInt Shipping in Firefox

#169

Post by qwerty456127 »

Gibbon1 wrote: post #106
qwerty456127 wrote: post #97

Now let's wait another decade before they add BigDecimal...

I think a friend of mine said he was in a meeting back when Javascript was being standardized. Mike Cowlishaw proposed that Javascript use REXX's Decimal type instead of IEEE 754. Everyone thought that was a really bad stupid idea.

It probably is when it's about "instead". IEEE 754 floating point computations are much much faster (given hardware support) while the precision is sufficient for most of the applications that don't have to deal with money.

Re: BigInt Shipping in Firefox

#170

Post by jchw »

SomeOldThrow wrote: post #136
jchw wrote: post #47

Earlier quoted context omitted.

To be fair, it really shouldn’t be conflated with ‘number’ - it isn’t the same thing, the behavior differs. And you can (and probably should) use small helper functions for these kinds of checks, pretty much for this kind of flexibility. Kind of curious what other libs (like lodash) will do.

I'm still holding out for an int type, I use a double about once a year but I'm completely insecure about using integer operations (e.g. div, mod, as an offset-based index) in javascript.

You can use w3c typed array stuff at least... though its obviously cumbersome.

Bitwise operators also coerce to integer, so they should roughly always be OK.

Post reply on HN