3 ms·

> create a really good upgrade path to implementing a proper bytecode into browsers. I think that's very unlikely to happen. Instead, what will happen will be

by beagle3 12y ago

> create a really good upgrade path to implementing a proper bytecode into browsers. I think that's very unlikely to happen. Instead, what will happen will be exactly "emterpreter"ing: There will be multiple bytescodes, and they will all ship with their own interpreters/compilers. If the emterpreter, instead of executing the bytecode, would generate JS code for it (and feed it into the JIT compiler if there is one), you'll get the best of all worlds -- bytecode format, top performance, perfect backwards compatibility. I suspect that's kripken's next move. Given that this is the case, why would someone want to shackle themselves to a specific bytecode format, which is practically impossible to get universally accepted? (This argument is supported by PNaCl; The technical problem is small; the political problem is huge). Work on JS optimization by all vendors is already extremely impressive and is not going to stop even if everyone agreed on some bytecode. Why not capitalize on it? What does a specific bytecode buy you beyond slightly shorter load times (which the emterpreter already gives a way to greatly reduce), and not having to pull the (essentially universally cached) emterpreter code? Because these two things, while nice, are not enough support for the revolution that a proper bytecode is.

vidarh 12y ago
As with asm.js it wouldn't need to be universally accepted: It can "sneak in the back door" by continuing to work fine in browers that "just" supports standard javascript. If code using this method clearly labels the bytecode and interpreter and the part that background loads the "real thing", then implementations can opt to add whatever optimisations they like to speed it up as it stabilises . Doesn't matter if the bytecode changes, as long as it's labelled properly so the optimised versions falls back to just interpreting the JS if it comes across a version (of the interpreter/bytecode as a whole, or just a single opcode) it doesn't understand (or that the implementer hasn't seen a need to optimise). If the interpreter is guaranteed to retain a certain structure, it could be very easy to just "unroll" the interpreter loop and selectively JIT portions of the bytecode based on hotspots. You can optimise that a lot in a non-bytecode specific way by annotating the interpreter loop with assertions that grants extra guarantees (immutable bytecode; markers to indicate which code is only interpreter scaffolding; decoding hints; if you also tack on "labels" for each instructions, implementations can special case on individual instructions that "settle" while still handling new instructions/changes by inlining the interpreter code. > What does a specific bytecode buy you beyond slightly shorter load times (which the emterpreter already gives a way to greatly reduce) The full speed from the start; note the substantially lower speed for the first little part. And the example codebase is small compared to some of the things people want to run. I think we sort-of agree. I don't necessarily think there's a reason to specify a standard bytecode, exactly because this approach could conceivably be extended to effectively give us a "mostly standard" bytecode with the freedom to continue to change the format without a lengthy committee approach, because there's a demonstrably viable fallback.

by beagle3 12y ago

vidarh 12y ago

As with asm.js it wouldn't need to be universally accepted: It can "sneak in the back door" by continuing to work fine in browers that "just" supports standard javascript. If code using this method clearly labels the bytecode and interpreter and the part that background loads the "real thing", then implementations can opt to add whatever optimisations they like to speed it up as it stabilises . Doesn't matter if the bytecode changes, as long as it's labelled properly so the optimised versions falls back to just interpreting the JS if it comes across a version (of the interpreter/bytecode as a whole, or just a single opcode) it doesn't understand (or that the implementer hasn't seen a need to optimise). If the interpreter is guaranteed to retain a certain structure, it could be very easy to just "unroll" the interpreter loop and selectively JIT portions of the bytecode based on hotspots. You can optimise that a lot in a non-bytecode specific way by annotating the interpreter loop with assertions that grants extra guarantees (immutable bytecode; markers to indicate which code is only interpreter scaffolding; decoding hints; if you also tack on "labels" for each instructions, implementations can special case on individual instructions that "settle" while still handling new instructions/changes by inlining the interpreter code. > What does a specific bytecode buy you beyond slightly shorter load times (which the emterpreter already gives a way to greatly reduce) The full speed from the start; note the substantially lower speed for the first little part. And the example codebase is small compared to some of the things people want to run. I think we sort-of agree. I don't necessarily think there's a reason to specify a standard bytecode, exactly because this approach could conceivably be extended to effectively give us a "mostly standard" bytecode with the freedom to continue to change the format without a lengthy committee approach, because there's a demonstrably viable fallback.