3 ms·

The code they are benchmarking is written in C, then compiled to asm.js (presumably with Emscripten). In one version, they remove the "use asm" header, but the

The code they are benchmarking is written in C, then compiled to asm.js (presumably with Emscripten). In one version, they remove the "use asm" header, but the code appears identical. That seems like a strange test. They aren't testing JS against ASM, or even compiled-to-vanilla-JS vs compiled-to-ASM. Both versions are compiled to ASM (complete with all strange annotations like num|0), only one has the asm optimizations disabled. I don't know enough about asm to know if their annotations are slower than vanilla JS in unoptimized engines, but I suspect they might be. I was also surprised that asm still won in Chrome - I thought Chrome optimized for asm-like code without checking for the "use asm" flag.

azakai 11y ago
> I don't know enough about asm to know if their annotations are slower than vanilla JS in unoptimized engines, but I suspect they might be. The opposite is true, for the most part. JS engines, even without asm.js optimizations, utilize the fact that the | operator emits a 32-bit integer (per the JS semantics), so it helps their type inference. (The engine needs to be good enough to get rid of the actual 0 value in the |0 coercions, but JS engines have been that good for several years now anyhow.) > I was also surprised that asm still won in Chrome - I thought Chrome optimized for asm-like code without checking for the "use asm" flag. Chrome detects "use asm", and enables TurboFan on such code. All JS engines today detect "use asm", except for JavaScriptCore.
- deleted 11y ago
  [deleted]