为何WebAssembly执行速度未显著快于JavaScript？

• 现代JS引擎的JIT优化已趋近极致
  像V8（Chrome/Node.js）、SpiderMonkey（Firefox）这类主流JS引擎都配备了多层即时编译（JIT）系统。对于反复执行的热点代码（比如FFT循环），引擎会先通过解释器快速启动，再将代码编译为高度优化的本地机器码——过程中会做类型推断、逃逸分析、循环展开、SIMD指令生成等优化，最终产出的机器码质量和WebAssembly编译后的结果相差无几。

• WebAssembly并非“原生机器码直接运行”
  WebAssembly是字节码格式，同样需要浏览器的Wasm引擎编译成本地机器码才能执行。虽然Wasm的设计更接近底层，但它的编译优化逻辑和JS JIT有很多重叠，并没有天然的“百倍性能优势”。如果Wasm代码编译时没开启最高级优化（比如-O3），或者没利用SIMD、多线程等特性，性能反而可能被优化后的JS反超。

• 测试场景的特殊性放大了JS的优势
  FFT这类算法依赖大量数组操作和数值计算，而现代JS引擎对TypedArray（比如Float32Array）的优化已经非常成熟，甚至能直接映射到底层硬件的SIMD指令。如果测试中的Wasm代码没启用SIMD扩展，或者JS代码用了更贴合引擎优化路径的写法（比如避免类型转换、使用连续内存布局），就会出现JS更快的情况。

• 性能收敛是当前Web技术的趋势
  随着Web标准的推进，JS和Wasm的性能边界一直在缩小。只有在极端场景下（比如需要手动精细控制内存、无分支的密集计算、调用底层系统接口），WebAssembly才会展现出明显的性能优势；绝大多数常规计算场景中，两者的表现已经趋于一致。

内容的提问来源于stack exchange，提问作者Carl Philip