You could already make video codecs in JS, or in C using asm.js. It is absolutely realistic; see for instance the jsmpeg project: https://github.com/phoboslab/jsmpeg.
It is unlikely to ever compete battery-wise with hardware support for a codec, however.
Right: direct hardware support can't be beat. Once WebAssembly has solid SIMD support and memory management that allows zero-copy then it should be* as good as it gets without direct hardware support.
* Assuming we're smart about security check elimination and SIMD codegen, which are both hard to do right.
Are you guys taking a look at Intel's ISPC language? I haven't seen anything even come close as far as SIMD speed goes. It is open and compiles to LLVM -> .o + .h files.
I don't know, but I doubt it. Maybe there is knowledge transfer there, but ISPC is a separate language that uses a 'varying' keyword to control whether a variable represents a SIMD 'gang' or not.
Oh but it is; see also asm.js, which is a subset of JS that removes a lot of the potential performance bottlenecks by removing those features from JS (mostly having to do with JS' dynamic nature, iirc).
Or in other words: javascript is an interpreted script language, webassembly is a compiled binary format.
Unoptimized JS compared to unoptimized C compiled to wasm is likely to be slower, although if you only care about hitting 60fps, it doesn't matter if the unoptimized JS already hits that consistently.
If you care about GC pauses, wasm is much less likely to be affected.
Finally, if you compare asm.js to wasm, wasm will have a speedier load time, especially for large projects.
> It's literally the same compiler in V8.
AFAIK, V8 has bailouts for JS code, while wasm code cannot bail out. It uses the same compiler as when JS code gets JITted, but it is AOT.
