7 ms·

A few points as an outsider about how asm.js could be considered a new VM: - PNaCl is different from a true "plugin technology" by being built into the browser

by comex 13y ago

A few points as an outsider about how asm.js could be considered a new VM: - PNaCl is different from a true "plugin technology" by being built into the browser, open, etc. Although browser vendors are not likely to stop competing on JavaScript speed, in a world where PNaCl is the "correct way" to run C/C++ code, C/C++ compiled to JavaScript will become far less important to optimize compared to hand-written, dynamic JavaScript: although of course there is overlap, the priorities are fairly different. - For optimum performance, some sort of ahead-of-time compilation is absolutely required. Although a "sufficiently smart compiler" might include ahead-of-time compilation for functions whose types are statically known or speculative specialized compilation in general, I do not think any JS engine currently does that or will do that soon, so in practice you're talking about a separate code path for asm.js. Not even close to the size of something like NaCl, but there. - Similarly, I have heard claims that a custom parser provides a significant speedup, and it's listed as a future project for OdinMonkey. This is probably only a tiny bit of code, but it also requires an explicit commitment to asm.js. - 50% C speed is not enough - I think everyone would like this to approach 100%. Although I don't think OdinMonkey currently does this, there would probably be a speedup by using virtual memory tricks - either reserving 4GB of address space for the heap to avoid having to explicitly check the validity of an array index, or doing something similar to NaCl, plus possibly even trying to detect and convert pointer-like integer arguments to real pointers. I think this is a good thing and should happen, but it very much falls into the territory of custom asm.js VM. - You might also get a performance increase by just replacing the optimizing compiler wholesale with LLVM? I don't know if this would actually yield a significant improvement, because a lot of the advanced optimizations would have already happened at an IR level in emscripten, and I suppose browser makers would be likely to incorporate whatever improvements into their JS engines rather than actually adopting LLVM, but I'm not sure I'd rule it completely out... - Some proposed JavaScript features are really mostly useful only for asm.js: multi-threaded access to ArrayBuffers plus locks (and there's no way asm.js can be competitive without that); function futures; GC hooks for JVM->asm.js. - And some that, while generally useful in some cases, feel aimed towards asm.js: BinaryData, value objects, SIMD (ala Dart, not Intel's high level stuff).

kevingadd 13y ago
AOT compilation really isn't required; sometimes JIT compilation is a real winner (like in those startup time cases Alon mentioned, but also in cases with constrained memory, like mobile) - sometimes 90% of the code in your app isn't going to be running most of the time, and it's much better to have 1-2ms pauses for things to be JITted or larger pauses behind a loading screen. The AOT compilation for asm.js is arguably a win primarily because it produces deterministic behavior (existing heuristics in SpiderMonkey and V8 are an ENORMOUS PAIN) and because it enabled them to get their existing IonMonkey code generator to produce better output. Those both justify the effort, I think, especially given how cheap it was to implement. All of those proposed features in your last two bullet points are useful for JSIL, which does not use asm.js. I can understand how people with a narrow understanding of JS look at these things and think 'these are all VM features for asm.js disguised as JS APIs!' because they don't understand, but they simply aren't. IIRC, Emscripten doesn't even benefit from Binary Data or Value Objects because it already has a virtual heap; that's not going to change.
- ori_b 13y ago
  With constrained memory, ahead of time wins by a long shot thanks to demand paging. You only need to allocate physical memory for code that is actually hit. With JIT code, you need to allocate space for the bytecode, allocate space for the linking, relocations, or whatever substitute you use (since bytecode typically isn't prelinked), allocate space for the JIT itself, and allocate space for the JITted output.
  - kevingadd 13y ago
    Sorry, I should be clearer - the kind of AOT compiles that OdinMonkey currently does do not benefit from demand paging, because the entire app is compiled from scratch at startup each time. If it generated executables on disk, then you could demand-page them in, just like the output from a traditional compiler. But I don't know if that has been proposed anywhere. I guess you could allocate guard pages for each function in the application and AOT-compile each function once on demand to simulate demand paging? Hm.
- 13y ago

by comex 13y ago

kevingadd 13y ago

AOT compilation really isn't required; sometimes JIT compilation is a real winner (like in those startup time cases Alon mentioned, but also in cases with constrained memory, like mobile) - sometimes 90% of the code in your app isn't going to be running most of the time, and it's much better to have 1-2ms pauses for things to be JITted or larger pauses behind a loading screen. The AOT compilation for asm.js is arguably a win primarily because it produces deterministic behavior (existing heuristics in SpiderMonkey and V8 are an ENORMOUS PAIN) and because it enabled them to get their existing IonMonkey code generator to produce better output. Those both justify the effort, I think, especially given how cheap it was to implement. All of those proposed features in your last two bullet points are useful for JSIL, which does not use asm.js. I can understand how people with a narrow understanding of JS look at these things and think 'these are all VM features for asm.js disguised as JS APIs!' because they don't understand, but they simply aren't. IIRC, Emscripten doesn't even benefit from Binary Data or Value Objects because it already has a virtual heap; that's not going to change.

ori_b 13y ago
With constrained memory, ahead of time wins by a long shot thanks to demand paging. You only need to allocate physical memory for code that is actually hit. With JIT code, you need to allocate space for the bytecode, allocate space for the linking, relocations, or whatever substitute you use (since bytecode typically isn't prelinked), allocate space for the JIT itself, and allocate space for the JITted output.
- kevingadd 13y ago
  Sorry, I should be clearer - the kind of AOT compiles that OdinMonkey currently does do not benefit from demand paging, because the entire app is compiled from scratch at startup each time. If it generated executables on disk, then you could demand-page them in, just like the output from a traditional compiler. But I don't know if that has been proposed anywhere. I guess you could allocate guard pages for each function in the application and AOT-compile each function once on demand to simulate demand paging? Hm.
13y ago