https://lukewagner.github.io/test-tanks-compile-time/ Firefox Nightly: WebAssembly.instantiate took 227.6ms (54.4mb/s) Chrome Canary: WebAssembly.instantiate took 8576ms (1.4mb/s) Wow. (Edit: And I believe that's not even using the streaming compilation mentioned in the article, it's just the new baseline compiler in action)
Chrome Dev: WebAssembly.instantiate took 2254 ms (5.5 MB/s) Firefox Nightly: WebAssembly.instantiate took 158.2 ms (78.3 MB/s) Edge 41.16299.15.0: WebAssembly.instantiate took 99.2 ms (124.8 MB/s) I did not expect Edge to be even faster.
Is the runtime performance similar to the startup performance measurement?
I guess i don't understand the push to wasm. Why not just embed hotspot, or a branch of it. Is there any difference? Or going the other way, could hotspot be replaced with a wasm jit by compiling java to wasm? I know they have slightly different memory models, but I don't understand why they seem to be treated so separately.
This was tried (search for "LiveConnect"). It failed for many reasons, but the one that's most relevant to today is probably that most interesting client-side stuff (that isn't already written in JS) is written in C and C++, not a JVM language.
https://lukewagner.github.io/test-tanks-compile-time/ Firefox Nightly: WebAssembly.instantiate took 227.6ms (54.4mb/s) Chrome Canary: WebAssembly.instantiate took 8576ms (1.4mb/s) Wow. (Edit: And I believe that's not even using the streaming compilation mentioned in the article, it's just the new baseline compiler in action)
Chrome Dev: WebAssembly.instantiate took 2254 ms (5.5 MB/s) Firefox Nightly: WebAssembly.instantiate took 158.2 ms (78.3 MB/s) Edge 41.16299.15.0: WebAssembly.instantiate took 99.2 ms (124.8 MB/s) I did not expect Edge to be even faster.
You can import C (and many others) libraries without re-implementing it in JS for browsers. In my company's case, we compile C-written libopus almost directly to encode audio streams into Opus on browsers, not on servers. In this way we benefit much less data traffic and server CPU loads.
>You can import C (and many others) libraries This means compiling the lib to wasm, right? At first I was thinking of running JS clientside that imports some C lib somehow, which confused me.
Yes. The C lib will be compiled into wasm. You can use the wasm-compiled code in a browser through JS wrappers. So you can say importing C lib on JS client side anyway.
Note that wasm's main objective is to run non-JS code on browsers, not for a faster JS.
A two-tier JIT. Interesting to see tiered JIT compilation catch on the way it has. I seem to remember a few years ago reading that the Java HotSpot team had given up on tiered JIT compilation as being not worthwhile. How far we've come. A whirlwind tour of todays JITs (apologies for the million links): .Net Core seems not to use tiered compilation. It never interprets the IR; everything is run through the same JIT co…
It should be the case that if the same amount of work is done, then the energy used will be the same. If it takes less work to compile the web assembly, then less energy (holding all other parameters the same). If you have to idle a CPU, then you probably use more energy (holding all other parameters the same) i.e. because you will spend more time and accomplish the same amount of real work (but waste energy on the i…
I don't think that's true; isn't the relationship between clock speed and power non-linear?
I think it is linear for frequency and non-linear for voltage, i.e. P~fCV^2. But in many current CPUS, the feature that adjusts frequency also adjusts voltage. That's why I stipulated that, for my comments to be true, such shenanigans as dynamic frequency (and voltage) scaling must be "turned off." I think the OP was asking, what happens to CPU energy if you load the web page with and without the optimized compilation. The OP was interested in core sleep states, but I think that dynamic frequency scaling is a confounding factor. It would be interesting to see the measurements w/ and w/out that feature perhaps.
I don't think that's true; isn't the relationship between clock speed and power non-linear?
That's for max frequency on a given process node. Power scales with voltage squared. But that doesn't say anything about wasted power. And dynamic scaling screws that up in modern chips. I believe I could summarize things by saying the only way you can really save energy* doing the same work+ is by using a different semiconductor process (either power/leakage-reduction-focused or smaller). * For serious values of "en…
Can you explain the voltage squared thing? To me, power = voltage * current.
I guess i don't understand the push to wasm. Why not just embed hotspot, or a branch of it. Is there any difference? Or going the other way, could hotspot be replaced with a wasm jit by compiling java to wasm? I know they have slightly different memory models, but I don't understand why they seem to be treated so separately.
This was tried (search for "LiveConnect"). It failed for many reasons, but the one that's most relevant to today is probably that most interesting client-side stuff (that isn't already written in JS) is written in C and C++, not a JVM language.
If that is why out failed, then wouldn't wasm fail for the same reason?
It looks like LiveConnect was a much bigger thing that MS pushed.
I'm not really understanding how this means anything. Why not just compile js et al to java bytecode? Or is wasm just another NIH protect in a long list of them in the JavaScript world? That is what it is looking like.
Sure hotspot itself couldn't be used straight up, but the changes are certainly much less than creating a whole new vm.
Is it actually a JIT? It's just compiling everything unconditionally. I guess the fact that the second tier replaces previously compiled functions with more optimized versions makes it a JIT? Or does the definition of JIT require recompiling in response to information about which code would benefit most?
> Is it actually a JIT? It's just compiling everything unconditionally. Still counts as JIT in my book, but you're right that it's a bit subtle. Unix-style configure/build/install isn't considered JIT. Installing a .Net application is pretty similar, but we don't consider it JIT. In the usual .Net model, what's distributed is IR rather than source-code. Compilation to native code happens at install time. The build-an…
It might be fun to make a source-based distribution where every binary in /usr/bin started off as a link to a script that built and installed the requested executable (over the top of the link), before executing it.
> Is it actually a JIT? It's just compiling everything unconditionally. Still counts as JIT in my book, but you're right that it's a bit subtle. Unix-style configure/build/install isn't considered JIT. Installing a .Net application is pretty similar, but we don't consider it JIT. In the usual .Net model, what's distributed is IR rather than source-code. Compilation to native code happens at install time. The build-an…
It might be fun to make a source-based distribution where every binary in /usr/bin started off as a link to a script that built and installed the requested executable (over the top of the link), before executing it.
Wouldn't be difficult to modify FreeBSD to do that. /usr/ports is just a little more than one indirection away.