6 ms·

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 us

by vngzs 7y ago

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/ https://tc39.github.io/proposal-bigint/ [1]: https://golang.org/src/hash/fnv/fnv.go https://golang.org/src/hash/fnv/fnv.go [2]: https://github.com/peterolson/BigInteger.js https://github.com/peterolson/BigInteger.js

wahern 7y ago
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.
- cwzwarich 7y ago
  > 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.
  - kevingadd 7y ago
    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.
    - cwzwarich 7y ago
      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 https://github.com/WebAssembly/design/issues/796, it seems that V8 and SpiderMonkey have roughly equivalent design constraints.
  - saurik 7y ago
    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.
    - cwzwarich 7y ago
      There are a few different performance issues with the Java bytecode verifier. Are you referring to this one? https://pdfs.semanticscholar.org/7dd2/b5359ab507fec1b1223db6edf5f58f9a28b6.pdf 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.
  - ghusbands 7y ago
    I have an interest in this - can you point at the earlier, superior research, please?
ClassyJacket 7y ago
Yeah - plus Javascript doesn't even support 32 bit integers.
- GordonS 7y ago
  Eh? What exactly is JavaScript's numeric type then? I always presumed it was a 32-bit, signed integer..
  - xtian 7y ago
    https://developer.mozilla.org/en-US/docs/Glossary/Number https://developer.mozilla.org/en-US/docs/Glossary/Number
  - vbezhenar 7y ago
    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.
    - ska 7y ago
      lua does the same thing. It's not crazy.
      - rayiner 7y ago
        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.
        nine_k 7y ago
        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.

by vngzs 7y ago

wahern 7y ago

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.

cwzwarich 7y ago
> 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.
- kevingadd 7y ago
  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.
  - cwzwarich 7y ago
    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 https://github.com/WebAssembly/design/issues/796, it seems that V8 and SpiderMonkey have roughly equivalent design constraints.
- saurik 7y ago
  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.
  - cwzwarich 7y ago
    There are a few different performance issues with the Java bytecode verifier. Are you referring to this one? https://pdfs.semanticscholar.org/7dd2/b5359ab507fec1b1223db6edf5f58f9a28b6.pdf 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.
- ghusbands 7y ago
  I have an interest in this - can you point at the earlier, superior research, please?

ClassyJacket 7y ago

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

GordonS 7y ago
Eh? What exactly is JavaScript's numeric type then? I always presumed it was a 32-bit, signed integer..
- xtian 7y ago
  https://developer.mozilla.org/en-US/docs/Glossary/Number https://developer.mozilla.org/en-US/docs/Glossary/Number
- vbezhenar 7y ago
  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.
  - ska 7y ago
    lua does the same thing. It's not crazy.
    - rayiner 7y ago
      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.
      - nine_k 7y ago
        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.