webassembly 在矩阵乘法中比 js 快，但仅当矩阵维度 ≥1024×1024 时才体现优势；因其绕开 js 内存拷贝、禁用 panic、复用线性内存并利用 simd，而小规模计算反因 wasm 启动与调用开销更慢。
WebAssembly 能显著加速浏览器端高维矩阵运算，但必须绕开 JS 内存拷贝、禁用 panic、复用线性内存，并在矩阵维度 ≥1024×1024 时才真正体现优势；盲目移植小规模计算反而更慢。
为什么 wasm 在矩阵乘法中比 JS 快，但不是所有尺寸都适用
JavaScript 的 Float32Array 在千万级元素（如 2048×2048）上遍历会明显卡顿，V8 对密集数值循环的优化存在瓶颈；而 wasm 使用线性内存 + 强类型 + SIMD 指令，能直接映射 C/Rust 的内存访问模式，避免动态类型检查与 GC 干扰。
- 实测临界点：输入矩阵 ≥1024×1024 且参与运算的张量不频繁重建时，wasm 才稳定快于纯 JS
- 若只是做 128×128 的单次 matmul，JS 的 for-loop + 内联可能更快——wasm 启动、
Module.ccall调用、new Float32Array(memory.buffer)拷贝的开销会吃掉全部收益 - 浮点精度敏感场景（如 softmax 归一化前的 logits 累加），wasm 的
f32行为比 JS 的Number更可控，误差累积更小
emcc 编译矩阵核心时必须设置的关键参数
用 Emscripten 编译 C++ 矩阵函数（如 matmul）时，胶水代码和导出配置直接影响调用效率与内存控制能力。
- 必须启用
-s WASM=1和-O3，禁用-s ASSERTIONS=1（否则 panic 会触发 JS 异常，打断推理流） - 导出函数需显式声明：
-s EXPORTED_FUNCTIONS='["_matmul"]'，避免符号被 LTO 优化掉 - 若需手动管理内存，加
-s ALLOW_MEMORY_GROWTH=1并在 Rust/C++ 中预留足够初始页（如-s INITIAL_MEMORY=67108864即 64MB） - 不要用
-s MODULARIZE=1，它生成异步初始化模块，首次调用await init()会阻塞主线程；改用-s EXPORT_ES6=1+type="module"配合同步加载
JS 侧调用时最常踩的三个内存坑
wasm 的性能红利几乎全系于内存交互效率。90% 的“wasm 没变快”问题，根源都在 JS 层反复分配/拷贝视图对象。
- 每次传入新数据都写
new Float32Array(input)→ 触发 GC + memcpy，应改为复用视图：inputView.set(input) - 未固定内存布局：Rust/C++ 中应预分配 input/output buffer offset（如 input 从 0x0 开始，output 从 0x100000 开始），JS 侧对应创建
const inputView = new Float32Array(memory.buffer, 0, size) - 在 requestAnimationFrame 循环中新建
Uint8Array(memory.buffer)→ 视图碎片化 + GC 压力陡增，动画帧率直接掉到 30fps 以下
何时该用 Web Worker + wasm，而非直接主线程调用
主线程调用 wasm 矩阵函数本身不阻塞渲染，但若单次推理耗时 >16ms（即一帧时间），仍会导致页面卡顿或输入响应延迟。
- 适用 Web Worker 的典型场景：Transformer 单层前向（含 LayerNorm + GEMM + SiLU），实测 >8ms 时就应剥离到 Worker
- Worker 中不能直接访问 DOM，所有 tensor 数据需通过
postMessage(..., [buffer])转移 ArrayBuffer，避免拷贝 - 务必启用
-s PTHREADS=1 -s PROXY_TO_WORKER=1编译，否则 Worker 内无法调用 wasm 函数 - 注意 Safari 目前不支持
SharedArrayBuffer在非 HTTPS 下启用，本地开发需用http-server -S启用 HTTPS
真正难的不是把矩阵乘法编译进 wasm，而是让 input/output buffer 在整个推理生命周期内只分配一次、地址不变、视图复用到底——这需要 C++/Rust 层主动暴露内存指针，JS 层彻底放弃“每次 new 一个新数组”的直觉。多数人卡在这一步，而不是编译或调用本身。
