4 ms·

Now please expose a loadFromByteCode api so that we can target bytecode instead of transpiling to js.

by singularity2001 7y ago

Conlectus 7y ago
This is, give or take, what web assembly is supposed to do, no?
- singularity2001 7y ago
  Wasm is a bytecode, but not js bytecode. In fact compiling js to wasm is very nontrivial / requires compiling it with a whole VM.
olliej 7y ago
The bytecode is an implementation detail that can, and does change. Making it an API would necessarily make changes (like this one) impossible.
- singularity2001 7y ago
  some standardization wouldn't harm. Then we can do loadFromByteCodeV1 and later loadFromByteCodeV2
  - olliej 7y ago
    No, it absolutely would. Because then any changes require duplicating the byte code parsers, and adding translation logic to manage those changes. You must understand: any change would be an API break, and API cannot change. Deprecating an API takes years. You also can't change/add API in security updates, which means if a security fix required changing some aspect of the bytecode that change couldn't be made. Lets say you change numbering of registers? Thats an API change. Lets say you change number of opcodes? API change. Any new API in macOS and iOS requires weeks of review cycle to ensure: * It solves a problem in a generic manner: e.g. it doesn't solve a very specific version of a general issue * It can be kept stable: e.g. it doesn't expose implementation details that may change * It is ABI stable: direct memory access APIs cannot expose layout that can vary based on any internal details. Shipping API is incredibly difficult if you care about ABI stability for software.
    - singularity2001 7y ago
      OK got it, thanks. So hopefully https://blog.cloudflare.com/binary-ast/ https://blog.cloudflare.com/binary-ast/ will become a standard. Already part of Firefox Nightly! about:config, unrestricted BinaryAST
      - olliej 7y ago
        binary-ast doesn't give any significant benefits over JS, potentially a small reduction in size vs standard gzip responses, but I've yet to see compelling evidence binast offers any significant time saving to first execution. It's important to realize: binary-ast is no more readily executable than plain JS, it is no more trustable than plain JS, and even if they were parsing is not been a significant part of ttfe in JSC in a long time. It's the interpreter codgen that eats up time, and the execution speed difference between AST (which JSC used for a looonng time, and the final builds beat the contemporary bytecode interpreters of other engines when it was replaced). The performance of an AST is so much slower than bytecode interpreter that you require a tiny amount of JS before the cost of codegen+execution beats just execution using the AST.
  - pizlonator 7y ago
    JSC makes breaking changes to the bytecode format on a regular basis. It’s an internal implementation detail and isn’t going to be exposed to standards. Also the bytecode format has no memory safety guarantees so standardizing it wouldn’t be a great idea. It’s only trusted to obey basic VM invariants if we know that we generated it ourselves.
bpye 7y ago
Don't the existing plans to expose GC [1] and ECMAScript objects [2] to WebAssembly cover this? [1] - https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16 [2] - https://github.com/WebAssembly/webidl-bindings/blob/master/proposals/webidl-bindings/Explainer.md https://github.com/WebAssembly/webidl-bindings/blob/master/p...
- singularity2001 7y ago
  Possibly. I'm a bit discouraged that ref's are opaque and cannot be mapped to wasm memory but maybe I missed something.
- skissane 7y ago
  I was thinking along the same lines as you, but kannanvijayan helpfully pointed out to me that it isn't that simple: https://news.ycombinator.com/item?id=19966100 https://news.ycombinator.com/item?id=19966100
bepvte 7y ago
Suprised no one has posted https://blog.cloudflare.com/binary-ast/ https://blog.cloudflare.com/binary-ast/ . Its not bytecode but its still a great idea
- singularity2001 7y ago
  Oh wow!! In a way it's even better than bytecode because it allows marking unused functions for lazy loading, giving speedups of 97% (in theoretical settings;) Must read. https://github.com/binast/binjs-ref https://github.com/binast/binjs-ref from below is part of this!
- kevingadd 7y ago
  WASM's (abandoned, because brotli is good enough) Binary Encoding proposal was essentially a binary AST compression system that worked for both JS trees (esprima) and wasm ASTs. You get pretty good improvements by converting ASTs into SoA representation, interleaving them, and then compressing them. Fast to decode, too. https://github.com/WebAssembly/design/issues/1180 https://github.com/WebAssembly/design/issues/1180
sroussey 7y ago
Chrome and Facebook are testing such a thing. I’ll look for the reference link. Maybe one of them can pipe up.
kevingadd 7y ago
This will never happen because it turns internal IR (subject to change) into a formalized format that people will depend on every detail of, including bugs. If you want bytecode, use wasm.

Now please expose a loadFromByteCode api so that we can target bytecode instead of transpiling to js.

Conlectus 7y ago

This is, give or take, what web assembly is supposed to do, no?

singularity2001 7y ago
Wasm is a bytecode, but not js bytecode. In fact compiling js to wasm is very nontrivial / requires compiling it with a whole VM.

olliej 7y ago

The bytecode is an implementation detail that can, and does change. Making it an API would necessarily make changes (like this one) impossible.

singularity2001 7y ago
some standardization wouldn't harm. Then we can do loadFromByteCodeV1 and later loadFromByteCodeV2
- olliej 7y ago
  No, it absolutely would. Because then any changes require duplicating the byte code parsers, and adding translation logic to manage those changes. You must understand: any change would be an API break, and API cannot change. Deprecating an API takes years. You also can't change/add API in security updates, which means if a security fix required changing some aspect of the bytecode that change couldn't be made. Lets say you change numbering of registers? Thats an API change. Lets say you change number of opcodes? API change. Any new API in macOS and iOS requires weeks of review cycle to ensure: * It solves a problem in a generic manner: e.g. it doesn't solve a very specific version of a general issue * It can be kept stable: e.g. it doesn't expose implementation details that may change * It is ABI stable: direct memory access APIs cannot expose layout that can vary based on any internal details. Shipping API is incredibly difficult if you care about ABI stability for software.
  - singularity2001 7y ago
    OK got it, thanks. So hopefully https://blog.cloudflare.com/binary-ast/ https://blog.cloudflare.com/binary-ast/ will become a standard. Already part of Firefox Nightly! about:config, unrestricted BinaryAST
    - olliej 7y ago
      binary-ast doesn't give any significant benefits over JS, potentially a small reduction in size vs standard gzip responses, but I've yet to see compelling evidence binast offers any significant time saving to first execution. It's important to realize: binary-ast is no more readily executable than plain JS, it is no more trustable than plain JS, and even if they were parsing is not been a significant part of ttfe in JSC in a long time. It's the interpreter codgen that eats up time, and the execution speed difference between AST (which JSC used for a looonng time, and the final builds beat the contemporary bytecode interpreters of other engines when it was replaced). The performance of an AST is so much slower than bytecode interpreter that you require a tiny amount of JS before the cost of codegen+execution beats just execution using the AST.
- pizlonator 7y ago
  JSC makes breaking changes to the bytecode format on a regular basis. It’s an internal implementation detail and isn’t going to be exposed to standards. Also the bytecode format has no memory safety guarantees so standardizing it wouldn’t be a great idea. It’s only trusted to obey basic VM invariants if we know that we generated it ourselves.

bpye 7y ago

Don't the existing plans to expose GC [1] and ECMAScript objects [2] to WebAssembly cover this? [1] - https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16 [2] - https://github.com/WebAssembly/webidl-bindings/blob/master/proposals/webidl-bindings/Explainer.md https://github.com/WebAssembly/webidl-bindings/blob/master/p...

singularity2001 7y ago
Possibly. I'm a bit discouraged that ref's are opaque and cannot be mapped to wasm memory but maybe I missed something.
skissane 7y ago
I was thinking along the same lines as you, but kannanvijayan helpfully pointed out to me that it isn't that simple: https://news.ycombinator.com/item?id=19966100 https://news.ycombinator.com/item?id=19966100

bepvte 7y ago

Suprised no one has posted https://blog.cloudflare.com/binary-ast/ https://blog.cloudflare.com/binary-ast/ . Its not bytecode but its still a great idea

singularity2001 7y ago
Oh wow!! In a way it's even better than bytecode because it allows marking unused functions for lazy loading, giving speedups of 97% (in theoretical settings;) Must read. https://github.com/binast/binjs-ref https://github.com/binast/binjs-ref from below is part of this!
kevingadd 7y ago
WASM's (abandoned, because brotli is good enough) Binary Encoding proposal was essentially a binary AST compression system that worked for both JS trees (esprima) and wasm ASTs. You get pretty good improvements by converting ASTs into SoA representation, interleaving them, and then compressing them. Fast to decode, too. https://github.com/WebAssembly/design/issues/1180 https://github.com/WebAssembly/design/issues/1180

sroussey 7y ago

Chrome and Facebook are testing such a thing. I’ll look for the reference link. Maybe one of them can pipe up.

kevingadd 7y ago

This will never happen because it turns internal IR (subject to change) into a formalized format that people will depend on every detail of, including bugs. If you want bytecode, use wasm.