Hacker News Reader

Comment by vngzs | Hacker News Reader

Here is the proposal[0].

There are important real use cases for this. I authored an implementation of the FNV64 hash function[1] at my last job. I needed to use the BigInteger.js[2] library. It truly surprised me that Javascript in 2018 did not support something so simple as 64-bit integers.

[0]: https://tc39.github.io/proposal-bigint/

[1]: https://golang.org/src/hash/fnv/fnv.go

[2]: https://github.com/peterolson/BigInteger.js

View on HN

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.

Yes, but in both cases this is because the JS runtimes (v8 in particular) makes it really difficult to feel okay with unconstrained control flow. The relooper may have been an influence but it was primarily pressure from the v8 people (I was in these meetings)

I'm less certain on my memory but I recall that Spidermonkey was more easily able to do fancier things with control flow.

I worked at Mozilla Research in the early days of Asm.js and sat next to that team. I would frequently tell them that they should support arbitrary control flow, and that there were better ways to achieve it with Emscripten than the Relooper. There wasn't much interest in improvements at the time, although it appears that the LLVM WebAssembly backend now uses a better approach.

While SpiderMonkey itself might support fancier things with control-flow, they were writing a separate compiler for Asm.js that relied on structured control flow for SSA construction, but I have no experience with how things evolved after that. Reading the thread at https://github.com/WebAssembly/design/issues/796, it seems that V8 and SpiderMonkey have roughly equivalent design constraints.

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.

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

Yeah - plus Javascript doesn't even support 32 bit integers.

Eh? What exactly is JavaScript's numeric type then? I always presumed it was a 32-bit, signed integer..

https://developer.mozilla.org/en-US/docs/Glossary/Number

JavaScript uses double. Though its precision is more than enough to support 32 bits. Actually it supports 53 bits for integers, then it gets imprecise.

lua does the same thing. It's not crazy.

Failing to distinguish between integer and floating point types is crazy. Not as crazy as TCL’s everything being a strong, but not the work of a mentally well person.

It's a work of RAM-constrained and time-constrained people in early 1990s, following approaches developed on 1970s for Lisp.

Packing as much as possible into a single cons cell, or a JS value, was (and is) important, so bit masking to distinguish between integers, floats, strings, functions, objects, was an inevitable approach.

Lisp has distinct integer and floating point types with the correct behavior for those types. At runtime they might get passed around as tagged data, but that’s not visible in the language semantics. In JavaScript, by contrast, the language exposes only a double float rule and you have to use floats where you’d otherwise use integers.

I agree. A Lisp may not make available all bits of a machine word to an integer, but they won't mix up an integer and a float.

JavaScript tried to make things artificially "simpler" by implicit conversions. As usual, the lack of consistency only lead to more eventual complexity than a sound solution would have in the first place.

"Numbers" actually conceal a lot of complexity.

Is 2 between 1.9 and 2.1? What about between 1.9 and 2.1111111111111111111111111111111111111111?

What about over/underflow? Do you wrap, clamp, throw an exception? Do you round or set +-inf? Can you divide by zero? Can you divide an integer by a floating point number, and if so what would the result be?

What happens if, say, you multiply an 8-bit and 16-bit integer and the result (using twos complement) doesn't fit in 8 bits?

"Use IEEE-754 doubles for everything" answers all these questions. I think JavaScript is basically junk, but I find at least this aspect to be rather elegant (to the point that I suspect it came from somewhere else, haha).

Lua 5.3 added 64-bit integers along with native bitwise operators. There's no end of bickering on the mailing-list over the finer details, but without a doubt 64-bit integers is a win.

> without a doubt 64-bit integers is a win

I'm not so sure about that. There is an alternative implementation of Lua called LuaJIT, which uses a similar NaN-tagging trick, and it also happens to be incredibly fast. LuaJIT uses the 5.1 version of the language, with some backported 5.2 features for compatibility, but it will likely never backport 64-bit integers from 5.3.

It's resulted in something like the Python 2/3 split. Except it's even worse because Lua has relatively little penetration as a general purpose scripting language, but is quite popular as a language that can be embedded in a program to add scripting capabilities. This means it's up to the developer of said program which version of Lua they choose to embed, and from what I can tell, most developers choose speed over 64-bit integer support.

> What exactly is JavaScript's numeric type then? I always presumed it was a 32-bit, signed integer.

It's not ideal to presume such a thing when there are ways to find out the answer, either from the link in a sibling comment or by observing JavaScript code that uses the Google Maps API or similar mapping APIs. How would you represent a latitude or longitude with a 32-bit integer?

I don't mean to pick on you. I have made these same kinds of assumptions too many times and it always got me in trouble.

Here's a particularly embarrassing example. When I did my first election results map for Google, I needed a way to represent the outline of a state. I saw that the Maps API supported polygons, so I thought "that's great, I can use a polygon for each state!"

Until the map went live and someone asked me "What happened to the northern part of Michigan [which isn't connected to the rest of the state]? And where are the rest of the Hawaiian Islands?"

It turned out that a single polygon wasn't enough to represent the outline of a state. Who would have guessed?

Don't let this happen to you. :-)

You are right. We can store and manipulate Int32 arrays as a typedarrays. The arithmetic is limited to a few operations.

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

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

Correct, but it is the only one to do so.

on 64bit archs it is 32bit

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

Reply on news.ycombinator.com