为什么向量指令是浏览器里最划算的一块性能，也是最容易白给的一块

先给你一个画面：一个用 Wasm 跑的 2D 弹幕游戏，屏幕上有 1800 颗子弹，每颗都要做位置积分、边界检测、与玩家胶囊体的碰撞判定。你把物理那一层单独计时，一帧花掉 9 毫秒，而整帧预算只有 16.6 毫秒。玩家的感受不是「帧率 45」，是「躲弹幕的时候手感发黏」——输入延迟一上来，躲不开就是躲不开，跟数字无关。

这时候你听说 WebAssembly 有 SIMD，一次能算四个浮点数。你的第一反应一定是：把编译选项一开，明天帧率翻倍。

我第一次干这事的时候，跑完 benchmark 差点以为测错了——整体快了 3%，某个场景甚至还慢了。不是我编译没生效，是我压根没搞明白：SIMD 的收益不来自那 128 位寄存器，来自你的数据在内存里是怎么排的。寄存器只是最后一步，前面每一步都在决定它能赚多少或者亏多少。

这篇文章我想把这件事讲透。因为对独立游戏来说，Wasm SIMD 是个很特殊的存在——它是浏览器里少数几个「不用减内容、不用降画质，纯靠工程手段白捡性能」的地方。别的优化都是做减法：少画点、少算点、少加载点。SIMD 是做乘法。但乘法有个前提，乘数得大于 1，你要是排布排错了，乘数是 0.7。

我会先讲清 128 位到底是个什么物理形态，再讲那个真正决定成败的指标——通道利用率，然后拆物理管线里哪一段能吃向量化、哪一段吃了会吐，最后聊图形侧那个反直觉的结论：算得快，不等于画得快。中间会拆两个真实案例：Rust 生态的物理引擎 Rapier，和 Godot 4 的 Web 导出——一个是正面教材，一个是「乘数再好也救不了底数」的活标本。

第一层：128 位到底是什么——把四个数当成一个数，而不是把数算得更快

先破一个最常见的误解。很多人脑子里 SIMD 是「更快的浮点运算」，像给 CPU 换了个更猛的发动机。不是的。SIMD 是换了一种数据形状：你不再处理「一个数」，你处理「一排数」，而且这一排必须整整齐齐地一起进、一起出、一起做同一个动作。

WebAssembly 的向量类型叫 v128，物理上是 16 个字节。这 16 个字节可以被解释成 4 个 32 位浮点、8 个 16 位整数、16 个 8 位整数，或者 2 个 64 位浮点。每个小格子叫一个「通道」（lane）。你执行一条加法，4 个通道同时加——不是 4 条指令并行，就是一条指令，硬件里铺了 4 份加法器。

理解了这层，你就能理解为什么它是 128 位而不是 256 位。这不是设计者小气，是被历史按住了头：1999 年 Intel 在 Pentium III 上把 SSE 的寄存器定成 128 位，之后延伸二十多年；ARM 的 NEON 也是 128 位。Wasm 的设计目标是「在所有平台上都一样快」，那它只能选交集，不能选并集。你们家 x86 有 256 位 AVX2，手机上没有，那 Wasm 就不给你。这点很关键——Wasm SIMD 的上限是被「跨平台一致性」这个目标锁死的，它天生不是性能天花板，它是性能地板。你想要更宽的向量，只能等 Relaxed SIMD 那一套（后面会讲），而 Relaxed 也不给你加宽。

指令层面，固定宽度 SIMD 提案给的是两百多条指令，按用途能分成几族。这张表你不用背，但要知道每一族解决什么问题：

落到玩家能感知的层面，这些指令换来的是什么？不是「帧率从 45 到 60」这种数字。是「同屏能放多少东西」。你做一个软体布料，Verlet 迭代每帧要跑 8 次约束求解，200 个质点的时候 CPU 上占 6 毫秒，向量化之后 1.8 毫秒——这 4 毫秒你可以拿去把布料从 200 个质点加到 500 个，或者把约束迭代从 8 次加到 20 次，布料的「软」和「不穿模」立刻不一样。再比如破坏系统，一次爆炸飞出 400 块碎片，每块都要算速度、旋转、与地面的接触——向量化省下来的时间直接变成碎片数量的预算，观感上的差别是「一堵墙碎了」和「一堵墙炸了」。

这里有个我自己的观察：SIMD 的收益从来不在「同样内容跑得更快」，而在「同样的时间预算塞进更多内容」。你要是把省下的时间拿去省电，那玩家感受不到；你要是拿去堆内容，玩家立刻能看见。这个取舍决定了你该怎么用它。

还有个现实问题——浏览器支持。固定宽度 SIMD 是 2021 年前后铺开的，Chrome 和 Firefox 走得快，Safari 慢了两拍，直到 2023 年春天才补上。这意味着你要是 2021、2022 年上线一个 Wasm 游戏，得准备两份包：一份带向量指令，一份纯标量兜底。包体大一圈，加载慢一点。这个账后面「参数化」那节再算。

第二层：数据布局——通道利用率这个指标，决定你是赚三倍还是亏三成

上一层的所有内容，其实都是背景知识。真正干活的时候，你 90% 的时间会花在这一层：你的数据在内存里是怎么排的。

假设你的游戏有 300 个刚体，每个刚体有位置（x、y、z）。第一种排法，按物体顺序排：物体 A 的 x、y、z，物体 B 的 x、y、z，以此类推。行话叫「数组套结构」。第二种排法，按分量排：先把所有物体的 x 排成一列，再把所有 y 排成一列，所有 z 排成一列。行话叫「结构拆成数组」。

用第一种排法做向量化，是一场灾难。你想同时算 4 个物体的 x 坐标，它们在内存里隔着 3 个位置，你得取 4 次、每次跨 12 个字节，然后把取到的 4 个值重新摆到一起。取 4 次加上一次重排，开销比标量算 4 次还大。这就是我开头说的「开了 SIMD 反而慢」的最常见原因。

用第二种排法，一次加载就是 4 个连续的 x，直接进寄存器，加完直接写回去。干净得像切豆腐。

那到底什么时候值得改成第二种？这引出本文最重要的一个概念：通道利用率。你的向量有 4 个通道，但如果实际参与计算的数据只有 2 个半，剩下一个半通道在空转，那你最多只能赚两倍，还要赔上重排和掩码的开销。我一般这么估算：

一个批次里同质元素的数量，最好在 64 到 512 之间。低于 64，批次的管理开销（分组、边界处理、最后不满 4 的尾巴）会吃掉大半收益；高于 512，缓存压力开始显现，尤其是你还要写回结果的时候。这个区间不是金科玉律，是经验值——粒子系统可以到几千个，因为它们简单到只做加减乘，而复杂凸包堆叠可能只有几十对，那向量化就很不划算。

第二个绕不开的东西是对齐。16 字节，是 v128 的自然边界。WebAssembly 本身不强制要求对齐，硬件也不会因为你没对齐就崩，但没对齐的时候，一条加载指令在某些平台上会被拆成两次内存访问，性能直接腰斩。更麻烦的是，从 JavaScript 那边传过来的缓冲区，起点未必是 16 字节对齐的——你以为你拿到的是一块整齐的内存，其实它是从某个偏移开始的。这个坑我在一个粒子渲染的项目里踩过：同样的代码，Chrome 上跑 60 帧，某国产浏览器的内核上掉到 40，查了两天才发现是缓冲区起点偏了 8 个字节。

第三个是分支。物理代码里到处是「如果穿透了就推开」这种判断。向量化的处理方式是：先把推开和不推开两条路都算一遍，然后用比较得到的掩码去选。代价是你要把两边的活都干完。所以如果一个循环里分支密到每条指令后面都跟着一个判断，向量化大概率是负收益。我的经验阈值是：分支比例（走不同路径的迭代占比）超过三成，就别硬上了，老老实实标量。这不是理论推导，是我为了一个「看起来很美」的向量化窄相模块，白白损失了一周才换来的教训。

顺便说个有意思的细节：Rust 生态里那个被广泛使用的数学库 glam，专门提供了面向 WebAssembly 向量指令的开关，但它默认是关的。你想用，得自己开。为什么默认关？因为一开，编译产物就必须依赖目标平台支持向量指令，你还得自己维护一条纯标量的备用路径，包体也要多一份。这个「默认关」的选择，本身就说明了 SIMD 在工程上的真实处境——它不是免费的，它是一笔需要你还利息的贷款。

第三层：物理管线拆解——哪一段能吃向量化，哪一段吃了会吐

物理引擎是个很适合拿来讲 SIMD 的解剖标本，因为它内部的分层特别清楚，每层的计算特征完全不同。我把一个典型的 2D/3D 刚体管线拆成五段，逐个告诉你收益在哪、坑在哪。

第一段，积分器。每个物体做「位置加上速度乘以时间步」、「速度加上加速度乘以时间步」，外加阻尼衰减。这是纯算术、无分支、数据完全同质，是向量化的天堂。300 个刚体、每帧一次积分，标量大概 0.4 毫秒，向量化后能压到 0.12 毫秒左右。看起来省得不多，但这段代码每帧都跑，而且它是最容易改的——你只要把位置数组按分量重排就行，不用动任何逻辑。我建议所有想试水 SIMD 的人都从这一段开始，因为它是「投入一天，立刻见效」的那种改造。

第二段，宽相（broadphase）。任务是快速筛掉明显不可能碰撞的物体对。常见做法是给每个物体算一个包围盒，然后按某个轴排序，只比较相邻的对象。包围盒更新和重叠测试本身可以向量化——四个物体的包围盒一起算、一起比，很顺。但排序不行。排序是数据搬移，不是算术，向量指令帮不上忙，你甚至可能因为要在数组里腾挪而变慢。所以宽相是个「一半甜一半苦」的地方，你得把两件事拆开做。

第三段，窄相（narrowphase）。真正算碰撞。这里要分情况：球对球、胶囊对胶囊、圆对圆这类同形体的批量检测，公式统一、分支少，向量化收益很好，两到三倍是能拿到的。但凸包对凸包的分离轴测试、或者 GJK 那类迭代算法，内部全是「找到当前最优轴、再沿着它继续搜」的循环——这种搜索型算法天生不适合向量化，你没法让四个通道各自跑各自的搜索还保持同步。一句话：同质形状批量算，能上；异构凸体单对算，别碰。

第四段，接触流形生成与约束装配。检测到碰撞之后，要生成接触点、法线、穿透深度，然后装配成约束方程。这一段内存写入很密集，还要动态分配（因为碰撞对的数量每帧都在变）。向量化的帮助有限，但它有个隐性收益：如果你把约束数据按「一批 4 个」的方式预先排好，后面的求解器就能吃满向量。所以这一段的价值不在于自己算得快，在于它决定了下一段能不能快。

第五段，约束求解器。整条管线里最肥的一块，通常占物理总耗时的四到六成。它本质上是大量小矩阵乘小向量、反复迭代收敛，天然向量化友好。但它有个工程难点：每帧的约束数量不同，你要么预分配一块足够大的内存池然后按批填，要么每次重新排布——前者省时间费内存，后者省内存费时间。我的建议是预分配加高水位线管理，池子按历史峰值的 1.5 倍开，别抠这点内存。

说完通用的，我们看一个真实的东西：Rapier。这是 Rust 生态里这几年很能打的物理引擎，官方提供了 WebAssembly 构建，浏览器里直接能用，配套的 JavaScript 绑定让做 Three.js 那套的人也能上手。它值得拿来讲，是因为它的架构里有一个设计，恰好说明了「为向量化铺路」是什么意思——岛管理。Rapier 会把互相接触、相互影响的刚体分到一个「岛」里，彼此独立的岛可以各自求解。这个分组动作本身不是为了 SIMD 写的，但它带来的副产品是：求解时拿到的是成批的、同质的、连续的约束，向量化几乎是顺手的事。

Rapier 的向量能力主要从数学库层渗进来——向量、四元数、矩阵的加乘运算。官方 demo 里的对比宣传，量级上比早期那些用 JavaScript 手写的物理库快好几倍，这个数字是真的，但你得看清楚它的测试场景：大量同质球体和方块堆叠。这恰恰是理想的向量化场景。你要是换成几十个复杂凸包互相挤压、外加几百个触发器在检测重叠，倍数会掉得非常难看，因为这时的瓶颈不在算术，在分支和访存。benchmark 是别人挑的场景，你的游戏不是别人的场景。这话我在别的地方说过好几次，在 SIMD 上尤其成立。

第四层：图形侧——算得快不等于画得快，交接成本才是真墙

物理讲完了，讲图形。这块的坑比物理更深，因为它多了一层「数据要交给显卡」的环节。

先看哪些图形计算适合向量化。顶点变换——每个顶点乘一个矩阵，几千上万个顶点，完全同质，教科书级的合适。骨骼蒙皮——每个顶点受四根骨骼影响，做四次加权累加，这个「四」简直是为 128 位量身定做的。粒子更新——位置、速度、生命周期，几万颗，闭着眼睛都能向量化。视锥剔除——把每个物体的包围球中心变换到裁剪空间，再和六个平面做距离判断，向量化之后剔除十万个物体的开销可以压到一毫秒以内。这些都很美好。

问题出在下一步：算完的数据怎么到 GPU 手里。

有两条路。第一条，你的顶点数据本来就住在 Wasm 的线性内存里——那块内存是一整片连续的字节，你可以直接把它的某个区间交给图形接口，说「从这里开始，按这个格式读」。这条路是零拷贝的，SIMD 算完原地不动，几乎没有额外开销。第二条，你的数据住在 JavaScript 那边——比如你用的是某个 JS 图形库的几何体对象，那你就得把 Wasm 里算好的结果一车一车搬回 JS 的数组里，或者反过来把 JS 的数据搬进 Wasm。这一趟搬运，足以把 SIMD 省下来的那两毫秒全吃回去，甚至还倒贴。

所以有个反直觉的结论：在 WebAssembly 游戏里，SIMD 图形加速能不能成立，不取决于你的指令写得多漂亮，取决于你的顶点数据最终住在谁家。这也是为什么我建议做浏览器 3D 的独立团队，尽早把几何数据的家安在 Wasm 内存里，让 JS 那边只负责「下指令」和「管资源」。这个架构决定一旦定错，后面再优化都是给错误的地基刷漆。

而且还有更外面的一层墙：GPU 的填充率和绘制调用数。你把顶点变换从 3 毫秒压到 0.8 毫秒，结果发现瓶颈是每帧 400 次绘制调用，那这 2.2 毫秒省下来对帧率毫无帮助。玩家看到的还是卡。SIMD 是乘法，不是加法；如果底数是渲染瓶颈，你乘多少都没用。

这里必须拆一个活标本：Godot 4 的 Web 导出。这是过去两年独立圈里被讨论最多、也被吐槽最多的东西之一。Godot 4 的 Web 构建是把整个引擎编成一个体量很大的 Wasm 模块，压缩后往往还在十兆以上；默认是单线程的，要用多线程得配特定的跨域隔离响应头，而很多托管平台给不了这个头，你只能单线程跑。引擎内部的向量数学、物理都是有的，但玩家在 itch.io 上的实际反馈很一致：能跑，物件一多就掉到二十几帧。

这个案例的价值不在于说 Godot 做得不好，而在于它精准地演示了「乘数救不了底数」。一个完整的引擎 Web 化之后，开销分布是：Wasm 模块加载与实例化、脚本层的 JS 胶水、渲染后端向 WebGL 的提交、以及主循环本身。物理和数学在里面可能只占百分之十几。你把这块向量化提速一倍，整体帧率的改善是个位数百分比，玩家根本感知不到。真正卡的是渲染提交和膠水层。你要是被 SIMD 的宣传一激励，跑去啃引擎里的数学模块，那就是在一个错误的地图上找宝藏。

反过来，什么样的项目适合上？小而薄的自研引擎，几何数据自己管、绘制调用自己合批、主循环只有几百行，SIMD 用在这里，配合一个稳定的数据结构，是真的能把「同屏一万个粒子」从幻灯片变成流畅动画。这就是独立开发者的优势——你的系统小到能整体看清瓶颈在哪。

参数化工具箱：一张能直接抄回去的配置表

前面都是道理，这节给能抄的东西。这些数字是我自己在几个项目里试出来的经验区间，不是标准答案，你按自己的场景微调。

再给你一张判定表，用大白话描述决策流程：

还有一个容易被忽略的账：包体。保留一份纯标量兜底路径，意味着某些代码编两遍，包体涨三到六成。对一个目标五兆的独立游戏来说，这是个实实在在的取舍。我的建议是看你的目标用户分布——如果你的玩家大部分在移动端 Safari 上，2023 年以前的设备还占相当比例，那就老实留双路径；如果是桌面端为主的硬核游戏，可以赌一把只发向量版本，但一定要在进入游戏前做一次能力检测，检测不过给个明确的提示，而不是让玩家对着一块黑屏猜。

初级用户速览：三步走，别想太多

如果你看完上面觉得「信息量有点大」，那就记住三句话。

第一步，先量。做任何改动之前，用浏览器自带的性能面板把物理、粒子、渲染的时间分别记下来。如果物理不占总帧时间的四分之一以上，那这篇文章对你现在没有用，关掉去做别的。这一步是所有优化的分水岭，跳过它的人最后都在优化一个不存在的问题。

第二步，改布局，别改指令。把你最热的那条循环的数据，从「一个物体一段」改成「一个分量一整条」。改完之后只用标量跑一遍——很多人会发现光这一步就快了，因为访存变连续了，缓存命中了。这一步骤的收益往往比你后面所有的向量化加起来还大，而且它不依赖任何新特性，风险为零。

第三步，先看编译器给不给你面子。很多编译器在开启向量指令目标之后，会自己把整齐的循环向量化。你先开开关跑一遍，用工具看看哪些循环真的被向量化了，剩下没被向量化的再考虑手写。手写向量指令是最后手段，不是第一手段——它意味着你要自己负责正确性、维护两条路径、还要处理边界上不满四个的尾巴。

再补一句大实话：如果你用的引擎本身就自带向量化的物理后端（不少商业引擎有），那你连第三步都不用做，去查文档、打开开关、确认目标平台支持，就完事了。SIMD 这个事，最赚的一步永远是「别人已经写好了，你把它打开」。

进阶用户深入：确定性、回退路径与验证方法

如果你已经决定要自己动手，那有三件事必须提前想清楚，否则后面全是坑。

第一件，确定性。固定宽度 SIMD 的指令是严格定义好的，同样的输入一定得到同样的输出，四位通道的加法顺序是确定的，所以做联机同步、录像回放是安全的。但「宽松向量指令」那一套提案不一样——它为了让硬件能选更快的实现，故意放宽了某些运算的结果精度，比如融合乘加、近似倒数、点积的求和顺序。这意味着同一个 Wasm 模块在不同 CPU 上跑，结果可能在最后几位有差异。单机游戏无所谓，但如果你做的是帧同步的联机物理、或者要给玩家存回放，这个差异会在几分钟后放大成「两个人的世界不一样了」。我的建议很干脆：联机部分完全不碰宽松指令，只在纯表现层（粒子、抖动、装饰性物理）用它。

第二件，回退路径的组织方式。别写成两套独立的代码分叉，那会变成维护地狱。正确的做法是把计算逻辑抽成一个「批量处理一组元素」的接口，向量实现和标量实现各填一份，上层完全不知道下面用的是哪套。这样你只需要在启动时检测一次能力，选定实现，然后全流程统一。关键是两套实现的输入输出契约要严格一致，包括边界情况下不足一批的尾巴怎么处理——这是最容易出分歧的地方，我见过因为尾巴处理不一致导致最后一个粒子永远停在原地的 bug。

第三件，怎么验证。这一步最多人跳过，然后翻车。方法很简单：把两套实现都跑起来，对同一批输入分别计算结果，逐元素比对，允许的误差范围按浮点精度定（比如十万分之一）。在开发期，每帧都跑这个比对，一旦发现差异立刻中断并打印出问题的那一组数据。这听起来很土，但它是唯一能让你在改了三个月物理代码之后依然敢按下发布键的东西。我吃过这个亏——一个向量化的接触求解器，在某些特定角度下会漏掉一个接触点，导致角色偶尔穿墙，玩家反馈零零散散，我查了两周。

最后给个心态上的建议：向量化是一项「收益递减非常陡」的优化。把最容易的那 20% 循环向量化，你能拿到七成的总收益；剩下 80% 的循环要花的力气是前面的五倍，加起来可能只多给你两成。做到哪一步停手，是个判断力问题，不是技术问题。我的经验是：当你的物理总耗时降到帧预算的 15% 以下，就该收工了，剩下的时间应该拿去加内容。

争议与五个真实的坑

顺便说个有争议的话题：WebAssembly 的 SIMD 到底值不值得独立开发者投入？我的看法是分人。如果你在做自研引擎、且物理或粒子确实是瓶颈，那它性价比很高，一周的活能换来实打实的同屏容量。如果你在用完整引擎做内容，那大概率不值得——引擎的瓶颈在别处，你就算把数学层优化到飞起，帧率也只会动个位数百分比。这个判断跟技术能力无关，跟你在项目里的位置有关。这话可能不中听，但能帮你省下两周。

FAQ

Q1：128 位是不是太窄了？现在原生平台都有 256 位甚至 512 位了。

是窄，而且这是刻意的。Wasm 的第一目标是「任何平台跑出一样的结果和相近的性能」，所以它只能取所有平台都有的那个宽度。你要是想要更宽，现阶段没有路径。但换个角度想：你原本一次算一个，现在一次算四个，这已经是四倍。对绝大多数独立游戏的物理和粒子来说，四个通道足够把瓶颈推走了。真正的瓶颈往往在别处。

Q2：我不写向量指令，只开编译开关，能有多少收益？

取决于你的代码长什么样。如果你的热循环已经是按分量排布的连续数组、没有复杂分支，编译器能自动向量化，收益可能有一倍多。如果数据是逐个物体排的、循环里全是判断，那基本为零甚至为负。所以别把开关当按钮按，先看数据布局。

Q3：手机上跑 Wasm 向量指令，会不会发热降频得厉害？

会，而且这是移动端特别需要注意的一点。向量指令让单位时间做的活变多，功耗也跟着上去。手机不像 PC，它有个严格的热预算，跑满几分钟之后会主动降频。所以移动端的策略应该反过来想：向量化不是为了跑得更快，是为了在同样的功耗预算里做更多事，然后把省下来的算力关掉。你可以在移动端设一个更低的帧率上限，或者动态降低粒子数量，让向量化的收益变成「更省电」而不是「更耗电」。

Q4：我用的是现成的引擎，怎么知道它有没有用上向量指令？

三个办法。第一，查它的发布说明和构建选项，看有没有提到向量指令支持，以及默认开不开。第二，把引擎的 Wasm 模块拿出来做静态分析，看里面有没有向量相关的指令——工具链里有现成的反汇编器可以做这件事。第三，也是最直接的，做个对照实验：同场景跑一次，然后在代码里加一段纯标量的对照实现，比较耗时比例。如果比例接近一倍，说明引擎那部分用了向量；如果是四倍，说明根本没用。

Q5：物理和图形，先优化哪个？

看你的游戏类型。动作类、弹幕类、塔防类，物理通常是热点，先做物理。粒子特效驱动的、视觉表现为主的，先做粒子。但有个前提永远成立：先确认渲染提交不是瓶颈。我见过太多项目在物理上抠了半天，最后发现瓶颈是每帧几百次绘制调用——那种情况下，你做一次合批的收益，超过把整个物理引擎向量化。

最后一个问题留给你自己：如果你的游戏同屏实体数量翻三倍，玩法会变得更好玩吗？如果答案是「会」，那 SIMD 就是个值得投入的方向，因为它的本质就是给你更多的实体预算。如果答案是「不会，我本来就是靠几个精心设计的角色撑场面」，那你大可以跳过这一整篇，把时间花在别的地方。技术选型的第一步，永远是问自己「我要这个东西干什么用」。