1. 项目概述：为什么游戏引擎必须死磕矩阵乘法？

做游戏引擎开发，尤其是渲染和物理模块，你绕不开的一个核心计算就是矩阵乘法。无论是将模型从本地空间变换到世界空间，还是从世界空间变换到观察空间，再到最终的屏幕空间，这一连串的变换本质上就是一连串的4x4矩阵乘法。一个复杂的场景可能有成千上万个物体，每帧都需要进行大量的矩阵运算。如果这里的性能出现瓶颈，那帧率下降、卡顿就是分分钟的事。

所以，优化矩阵乘法，是每个引擎底层开发者必须面对的硬仗。传统的逐元素循环写法虽然清晰，但效率在现代CPU架构下远远不够看。今天要聊的，就是如何利用现代CPU的SIMD指令集，并结合矩阵转置这一经典技巧，将矩阵乘法的性能提升一个数量级。这不仅仅是“写个更快的函数”，而是理解CPU如何工作、内存如何访问，并让算法与之共舞的过程。如果你正在为你的C++游戏引擎寻找性能突破口，或者对底层优化感兴趣，这篇实战经验分享应该能给你不少启发。

2. 核心思路与方案选型：从标量到SIMD，从行主序到列主序

在动手写代码之前，我们必须把思路理清楚。优化不是盲目的，每一步选择背后都有其硬件和数学原理。

2.1 为什么是SIMD？

SIMD，全称单指令多数据流。简单来说，就是一条指令可以同时处理多个数据。对于我们的4x4矩阵（元素通常是32位浮点数），一个128位的SIMD寄存器（如x86的XMM，ARM的Neon）正好可以容纳4个float。这意味着，理想情况下，我们原本需要4条指令完成的4个浮点运算，现在可能1条指令就搞定了。这种并行性是突破标量计算瓶颈的关键。

在C++中，我们主要有几种方式使用SIMD：

1. 编译器自动矢量化：在循环简单规整时，开启编译优化（如-O2，-O3，/O2）后，编译器可能会自动生成SIMD指令。但对于矩阵乘法这种稍复杂的访存模式，编译器往往力不从心。
2. 使用 intrinsics（内联函数）：这是最直接、最可控的方式。 intrinsics 是编译器提供的一组与机器指令一一对应的C函数，让你能以接近汇编的精度控制SIMD寄存器。虽然牺牲了部分可移植性（不同架构的intrinsics不同），但为了极致的性能，这在引擎开发中是常态。本文将主要基于x86/x64平台的SSE/AVX intrinsics进行讲解。
3. 使用库（如Eigen， GLM）：这些库在内部已经实现了高度优化的SIMD矩阵运算。如果你的项目不追求极致的定制化或想快速上手，它们是绝佳选择。但理解其底层原理，对于调试和解决更深层的问题至关重要。

我们的选择是方案2，因为我们要深入原理，并打造属于自己引擎的核心数学库。

2.2 为什么需要转置？行主序与列主序的战争

这是矩阵乘法优化中一个经典且容易混淆的点。首先明确两个概念：

• 行主序：在内存中，矩阵的每一行是连续存储的。C/C++的原生二维数组就是行主序。
• 列主序：在内存中，矩阵的每一列是连续存储的。OpenGL的GLSL着色器语言默认采用列主序（虽然可以通过layout关键字修改），而DirectX的HLSL默认是行主序。

假设我们有一个4x4矩阵M，计算一个向量v（列向量）的变换：v' = M * v。

• 如果M是列主序，那么矩阵M的每一列在内存中是连续的。计算v'的每个分量时，需要取v的所有分量，分别与M的某一列的所有元素进行点积。这非常适合SIMD操作：我们可以一次性加载M的一列（4个连续的float）到一个SIMD寄存器，再通过一系列 shuffle 和乘加操作与向量v进行计算。
• 如果M是行主序，那么每一行是连续的。计算时需要取M的某一行与向量v进行点积。虽然也能做，但在实现某些优化（特别是后面会讲的SoA转置技巧）时，不如列主序直观和高效。

在游戏引擎中，为了与图形API（尤其是传统的OpenGL）和着色器端匹配，数学库常常选择列主序存储。但这带来了一个挑战：我们写的C++代码，用二维数组float m[4][4]定义矩阵，默认是行主序。这就产生了存储顺序与运算期望顺序的不匹配。

转置加速的核心思想：对于矩阵乘法 C = A * B，如果我们提前将B矩阵转置（假设我们采用列主序思维），那么计算C的每个元素时，原本需要遍历B的一列，现在变成了访问B转置后的一行。由于转置后，我们所需的数据在内存中是连续存放的，这极大地提高了缓存命中率和SIMD加载的效率。简单说，用一次转置的开销，换取后续无数次乘法运算中连续内存访问的收益，在批量处理矩阵时尤其划算。

我们的优化路线图因此确定：实现一个基于列主序存储、利用SIMD intrinsics、并可选结合预转置进行加速的4x4矩阵乘法。

3. 基础实现与SIMD优化实战

让我们从最基础的版本开始，逐步迭代到优化版本。假设我们的矩阵采用一个一维数组float data[16]按列主序存储。索引方式为：第i行第j列的元素是data[i + j*4]。

3.1 朴素的标量实现

这是理解算法的起点，也是性能的基线。

void MatrixMultiplyScalar(const float* A, const float* B, float* C) { for (int i = 0; i < 4; ++i) { // 行 for (int j = 0; j < 4; ++j) { // 列 float sum = 0.0f; for (int k = 0; k < 4; ++k) { // 内积 sum += A[i + k*4] * B[k + j*4]; // 注意列主序索引 } C[i + j*4] = sum; } } }

这个实现清晰易懂，但问题很多：三层嵌套循环、大量的索引计算、无法利用缓存和指令级并行。接下来我们用SIMD改造它。

3.2 使用SSE Intrinsics进行向量化

我们使用SSE指令集，需要包含<xmmintrin.h>（SSE）和<emmintrin.h>（SSE2）等头文件。核心思路是：计算输出矩阵C的一整列。

为什么按列计算？因为我们的矩阵是列主序，C的一列数据在内存中是连续的（data[0], data[1], data[2], data[3]），计算完成后可以用一条_mm_store_ps指令直接写回内存，非常高效。

计算C的第j列，公式是：C[:,j] = A * B[:,j]。即A矩阵乘以B的第j列。 对于列主序的B，B[:,j]在内存中是连续的，我们可以用_mm_load_ps加载它。但A矩阵的每一列是连续的，而计算需要A的行元素。这里就需要用到SIMD的乘加指令和shuffle（重排）操作。

#include <xmmintrin.h> #include <emmintrin.h> void MatrixMultiplySSE(const float* A, const float* B, float* C) { // 假设A, B, C都是16字节对齐的，这对_mm_load_ps很重要 for (int j = 0; j < 4; ++j) { // 遍历C的每一列 // 加载B的第j列到向量b __m128 b_col = _mm_load_ps(&B[j * 4]); // 计算C的第0行第j列的元素：需要A的第0行与B的第j列点积 // A的第0行元素是：A[0], A[4], A[8], A[12] __m128 a_row0 = _mm_set_ps(A[12], A[8], A[4], A[0]); // 注意顺序，set_ps参数是倒序的 __m128 m0 = _mm_mul_ps(a_row0, b_col); // 计算C的第1行第j列的元素：A的第1行与B的第j列点积 __m128 a_row1 = _mm_set_ps(A[13], A[9], A[5], A[1]); __m128 m1 = _mm_mul_ps(a_row1, b_col); // 计算C的第2行第j列的元素 __m128 a_row2 = _mm_set_ps(A[14], A[10], A[6], A[2]); __m128 m2 = _mm_mul_ps(a_row2, b_col); // 计算C的第3行第j列的元素 __m128 a_row3 = _mm_set_ps(A[15], A[11], A[7], A[3]); __m128 m3 = _mm_mul_ps(a_row3, b_col); // 现在 m0, m1, m2, m3 每个向量里都包含了4个乘积，需要水平相加（点积） // SSE3提供了方便的水平相加指令 _mm_hadd_ps // 如果没有SSE3，则需要通过shuffle和add实现，稍复杂 // 这里使用SSE3的 hadd // haddps 指令： dst[0] = a[0] + a[1]; dst[1] = a[2] + a[3]; // dst[2] = b[0] + b[1]; dst[3] = b[2] + b[3]; __m128 sum01 = _mm_hadd_ps(m0, m1); // [m0[0]+m0[1], m0[2]+m0[3], m1[0]+m1[1], m1[2]+m1[3]] __m128 sum23 = _mm_hadd_ps(m2, m3); __m128 result = _mm_hadd_ps(sum01, sum23); // 最终结果在一个寄存器里，但顺序是交错的 // 将结果存储到C的第j列。result中的顺序是 [C[0,j], C[1,j], C[2,j], C[3,j]]? 不一定，需要测试或调整hadd顺序。 // 更通用的方法是使用 shuffle 来整理顺序。一个常见且高效的整理方法是： // 1. 对 m0, m1, m2, m3 进行第一次横向相加（使用 _mm_add_ps 和 shuffle） // 2. 将四个标量结果组合成一个向量。 // 下面是一种不依赖SSE3 hadd的实现，更清晰且可控： } }

上面用_mm_set_ps构建行向量其实效率不高，因为它可能生成多条指令。更好的方法是直接加载A的列，然后通过shuffle来得到行向量。同时，点积的最终归约（求和4个乘积）也有更优的实现。我们重写一个更高效的版本：

void MatrixMultiplySSE_Optimized(const float* A, const float* B, float* C) { // 提前加载A的全部4列到寄存器，避免在循环中重复加载 __m128 A_col0 = _mm_load_ps(&A[0]); __m128 A_col1 = _mm_load_ps(&A[4]); __m128 A_col2 = _mm_load_ps(&A[8]); __m128 A_col3 = _mm_load_ps(&A[12]); for (int j = 0; j < 4; ++j) { // 加载B的第j列 __m128 B_col = _mm_load_ps(&B[j * 4]); // 为了计算点积，我们需要A的行向量与B_col相乘。 // 例如，C[0][j] = A[0][0]*B[0][j] + A[0][1]*B[1][j] + A[0][2]*B[2][j] + A[0][3]*B[3][j] // 在列主序下，A的行元素分布在不同的列向量中。 // 我们可以通过 shuffle 从A的列向量中提取出同一行的元素，组成行向量。 // 计算C的第0行第j列：需要A的第0行。 // 从A_col0, A_col1, A_col2, A_col3中分别取出第0个元素。 __m128 A_row0 = _mm_set_ps(A_col3.m128_f32[0], A_col2.m128_f32[0], A_col1.m128_f32[0], A_col0.m128_f32[0]); // 但直接访问 .m128_f32 不是标准的portable方式。标准做法是用shuffle intrinsic。 // 使用 _mm_shuffle_ps 来构建行向量： // _mm_shuffle_ps(a, b, _MM_SHUFFLE(z, y, x, w)) 从a中取w,x分量，从b中取y,z分量。 // 我们需要从A_col0和A_col1中构建包含A[0][0]和A[0][1]的向量，以此类推。 // 一个更清晰且高效的方法是使用 _mm_dp_ps (SSE4.1的点积指令)，但它不是所有平台都支持。 // 我们使用通用的乘加和横向相加。 // 方法：分别计算A的每一列与B_col的对应分量的乘积，然后累加。 // C_col_j = A_col0 * B_col[0] + A_col1 * B_col[1] + A_col2 * B_col[2] + A_col3 * B_col[3] // 这正好是矩阵乘法的列视角！结果就是C的第j列。 // 将B_col的每个分量广播（splat）到一个完整的向量 __m128 b0 = _mm_shuffle_ps(B_col, B_col, _MM_SHUFFLE(0, 0, 0, 0)); // 所有分量都是B_col[0] __m128 b1 = _mm_shuffle_ps(B_col, B_col, _MM_SHUFFLE(1, 1, 1, 1)); // 所有分量都是B_col[1] __m128 b2 = _mm_shuffle_ps(B_col, B_col, _MM_SHUFFLE(2, 2, 2, 2)); __m128 b3 = _mm_shuffle_ps(B_col, B_col, _MM_SHUFFLE(3, 3, 3, 3)); // 分别与A的对应列相乘，然后相加 __m128 result = _mm_add_ps( _mm_add_ps(_mm_mul_ps(A_col0, b0), _mm_mul_ps(A_col1, b1)), _mm_add_ps(_mm_mul_ps(A_col2, b2), _mm_mul_ps(A_col3, b3)) ); // 存储结果到C的第j列 _mm_store_ps(&C[j * 4], result); } }

这个版本就高效多了。它完全在寄存器中操作，循环体内只有加载B的一列、4次shuffle广播、4次乘、3次加，以及一次存储。计算C的一列完全并行，没有冗余的内存访问。

注意：这里有一个关键点，我们利用了列主序的特性，将矩阵乘法C = A * B解释为C的每一列是A矩阵乘以B的对应列。这个视角让SIMD向量化变得非常自然：一次计算产出连续内存的4个float（C的一列）。

3.3 引入转置：SoA与AoS的内存布局思维

上面的SSE优化已经很快了，但它仍然在循环中为每个B的列进行shuffle广播操作。如果我们需要连续计算很多个矩阵乘法（比如蒙皮动画中计算所有骨骼的变换矩阵），或者计算C = A * B^T（这在视图变换、法线变换中很常见），我们可以通过提前转置B来获得进一步加速。

转置的核心目的是将内存访问模式从“跨步”变为“连续”。在之前的计算中，为了得到b0, b1, b2, b3，我们需要从B_col中重复shuffle。如果我们提前将B转置，那么转置后的矩阵B_T的每一行就是原来B的每一列。这时，计算C = A * B就变成了C = A * B_T^T？不对。实际上，如果我们有B_T（B的转置，行主序存储），且我们仍按列主序思维去用它，计算会变复杂。

更实用的场景是C = A * B^T。很多图形API的常量缓冲区要求矩阵按列主序存储，但Shader中可能以行向量左乘矩阵（即v * M），这等价于M^T * v^T。在这种情况下，如果我们提前计算好B^T并存储，那么Shader中的乘法就变成了连续的内存访问。

但对我们当前C = A * B的优化，一个更直接的“转置”思想是改变数据的组织方式，即使用SoA结构。

• AoS：数组结构体。这是我们常用的，一个矩阵是一个结构体，里面有16个float连续存放。
• SoA：结构体数组。例如，我们有一个包含N个矩阵的数组。AoS布局是[M0_00, M0_01, ... M0_33, M1_00, M1_01, ...]。而SoA布局是[M0_00, M1_00, ... MN_00, M0_01, M1_01, ...]，即所有矩阵的第(0,0)元素连续存放，然后是所有矩阵的第(0,1)元素，以此类推。

对于SIMD来说，SoA是天堂。因为SIMD寄存器一次加载4个float，在SoA布局下，一次加载正好是4个不同矩阵的同一个位置元素。这对于批量处理（如处理1000个顶点变换）是极大的优化。这本质上是一种“转置”，将数据从“单个矩阵的行/列连续”转换为“多个矩阵的同一分量连续”。

实现一个SoA版本的矩阵批量乘法是一个更大的话题，但原理与我们上面单矩阵的列计算类似，只是现在我们的A_col0寄存器里装的不再是单个矩阵A的第一列4个元素，而是4个不同矩阵各自的第一列的第一个元素。计算时需要仔细设计数据加载和存储的流程。

4. 进阶优化与AVX实践

SSE的寄存器是128位，处理4x4矩阵刚合适。但现代CPU普遍支持AVX（256位寄存器）甚至AVX-512（512位寄存器）。使用AVX，我们可以同时处理8个float。对于4x4矩阵，我们可以用AVX同时计算两列！这需要将两个相邻的列数据打包到一个256位寄存器中。

4.1 AVX双列计算

思路：将矩阵B的两列（比如第j列和第j+1列）同时加载到一个__m256寄存器中。同样，我们需要将A的每一列广播到256位寄存器，并与B中对应的双列数据相乘。由于A的一列是4个float，我们需要将它广播到256位寄存器的低128位和高128位。这可以使用_mm256_broadcast_ps（需要AVX）或组合_mm256_set_m128来实现。

#include <immintrin.h> // AVX void MatrixMultiplyAVX(const float* A, const float* B, float* C) { // 加载A的列到128位寄存器，稍后广播 __m128 A_col0 = _mm_load_ps(&A[0]); __m128 A_col1 = _mm_load_ps(&A[4]); __m128 A_col2 = _mm_load_ps(&A[8]); __m128 A_col3 = _mm_load_ps(&A[12]); // 每次处理两列 for (int j = 0; j < 4; j += 2) { // 加载B的第j列和第j+1列 __m128 B_col_j = _mm_load_ps(&B[(j) * 4]); __m128 B_col_jp1 = _mm_load_ps(&B[(j+1) * 4]); // 将两列打包到一个256位寄存器中，低128位是col_j，高128位是col_jp1 __m256 B_col_pair = _mm256_set_m128(B_col_jp1, B_col_j); // 将A的每一列广播到256位，并与B_col_pair中对应的“双分量”相乘 // 首先，需要将A的列（128位）广播到256位。 // _mm256_broadcast_ps 可以从128位内存广播，但这里我们已经有了寄存器。 // 我们可以使用 _mm256_insertf128_ps 和 _mm256_castps128_ps256 来构造。 // 更简单的方法：使用 _mm256_set_m128(A_col0, A_col0) 来创建两个相同的副本。 __m256 A_col0_256 = _mm256_set_m128(A_col0, A_col0); __m256 A_col1_256 = _mm256_set_m128(A_col1, A_col1); __m256 A_col2_256 = _mm256_set_m128(A_col2, A_col2); __m256 A_col3_256 = _mm256_set_m128(A_col3, A_col3); // 现在，我们需要将B_col_pair中的每个分量（共8个float）分别广播，以便与A的列相乘。 // B_col_pair 的布局是 [b0j, b1j, b2j, b3j, b0(j+1), b1(j+1), b2(j+1), b3(j+1)] // 我们需要得到： // b0: [b0j, b0j, b0j, b0j, b0(j+1), b0(j+1), b0(j+1), b0(j+1)] // b1: [b1j, b1j, b1j, b1j, b1(j+1), b1(j+1), b1(j+1), b1(j+1)] // ... 以此类推。 // 这需要复杂的跨通道shuffle（如 _mm256_permutevar8x32_ps）。实现起来比SSE版本复杂得多。 // 鉴于4x4矩阵的特殊性，用AVX同时算两列带来的收益可能被复杂的shuffle开销抵消。 // 一个更实际的做法是：用AVX来加速单个矩阵乘法中多个独立乘加运算的融合，或者用于处理SoA布局的批量矩阵。 } }

如代码注释所述，用AVX优化4x4矩阵乘法，在单矩阵场景下，由于数据重组（shuffle/permute）的开销增大，可能无法获得线性提升（2倍）。AVX的优势在于更宽的寄存器，更适合处理：

1. 更大的矩阵（如8x8）。
2. SoA布局下的批量小矩阵运算。
3. 单指令内完成更多的乘加运算（FMA指令，如_mm256_fmadd_ps）。

4.2 使用FMA指令

FMA（融合乘加）指令能在一条指令内完成a * b + c操作，且精度更高（只做一次舍入）。现代CPU（如Haswell及以后的Intel，推土机以后的AMD）都支持AVX2和FMA。使用FMA可以进一步减少指令数量。

将我们SSE优化版本中的_mm_add_ps(_mm_mul_ps(a, b), c)替换为_mm_fmadd_ps(a, b, c)。AVX版本同理，使用_mm256_fmadd_ps。

// 使用FMA指令的SSE版本核心计算部分 __m128 result = _mm_fmadd_ps(A_col0, b0, _mm_fmadd_ps(A_col1, b1, _mm_fmadd_ps(A_col2, b2, _mm_mul_ps(A_col3, b3)))); // 注意：最内层是mul，外层嵌套fmadd。也可以全部用fmadd，将初始累加值设为0。 __m128 result = _mm_setzero_ps(); result = _mm_fmadd_ps(A_col0, b0, result); result = _mm_fmadd_ps(A_col1, b1, result); result = _mm_fmadd_ps(A_col2, b2, result); result = _mm_fmadd_ps(A_col3, b3, result);

使用FMA通常能带来几个百分点的性能提升，并且是迈向现代CPU优化的重要一步。

5. 性能对比、常见问题与避坑指南

理论再好，也要跑分说话。我写了一个简单的测试程序，在相同环境下（编译器MSVC /O2， CPU i7-12700K），循环执行1000万次矩阵乘法，计算耗时。

可以看到，手动SIMD优化带来了数量级的提升。但优化路上坑也不少，下面是一些实战中总结的经验和陷阱。

5.1 内存对齐是生命线

SIMD指令如_mm_load_ps要求内存地址是16字节对齐的（AVX的_mm256_load_ps要求32字节对齐）。如果传入未对齐的指针，会导致程序崩溃（触发硬件异常）。你必须确保你的矩阵数据是对齐的。

如何保证对齐？

• C++11/17： 使用alignas关键字。alignas(16) float data[16];
• 动态内存： 使用_aligned_malloc(Windows) 或aligned_alloc(C11/C++17) 或posix_memalign(Linux) 来分配。
• 编译器扩展： 对于栈上变量，某些编译器有__declspec(align(16))(MSVC) 或__attribute__((aligned(16)))(GCC/Clang)。
• STL容器：std::vector默认不保证对齐。可以使用自定义分配器，或者使用Eigen/GLM等库内置的类型。

踩坑记录：曾经在将矩阵数据作为类成员时，没有注意整个类的对齐，导致在堆上创建对象后，其内部的矩阵数组并未16字节对齐，一调用SIMD版本就崩溃。解决方法是将整个类也用alignas(16)修饰。

5.2 编译器指令集开关

你的代码里用了SSE、AVX或FMA的intrinsics，必须告诉编译器启用对应的指令集支持，否则编译器可能无法生成正确的指令，或者生成效率低下的备用代码。

• MSVC:/arch:AVX2(启用AVX2和FMA)，/arch:AVX，/arch:SSE2
• GCC/Clang:-mavx2 -mfma,-mavx,-msse4.2,-msse2

一个更安全的做法是使用CPU派发：在运行时检测CPU特性，动态选择最优的函数实现。这可以通过cpuid指令或编译器内置函数（如GCC的__builtin_cpu_supports）来实现。

5.3 Shuffle操作是性能双刃剑

Shuffle（_mm_shuffle_ps）和更复杂的permute操作是SIMD编程中重组数据的关键，但它们本身也有延迟和吞吐成本。在设计算法时，应尽量减少不必要的shuffle。在我们列计算的SSE版本中，我们将B的每个分量广播（splat）了4次，这产生了4次shuffle。如果这个乘法在更内层的循环（比如对很多向量进行变换），那么提前将B的每一行（转置后）广播好，可能会更优。这再次体现了“转置”思想的应用场景。

5.4 精度与舍入模式

SIMD浮点运算的精度和舍入模式与标量浮点运算基本一致，遵循IEEE 754标准。但在极端情况下，由于指令执行顺序的细微差别（比如乘加融合），SIMD结果可能与标量结果在最低有效位上存在差异。对于图形学应用，这通常可以接受。但对于严格的科学计算，需要仔细评估。

5.5 测量，测量，再测量

任何优化都必须以精确的测量为依据。不要凭感觉。使用高精度计时器（如C++11的std::chrono::high_resolution_clock，或平台的特定API如QueryPerformanceCounter）。在测量时，要确保测试数据足够多，避免缓存和分支预测的偶然性，并关闭调试模式，在发布优化模式下进行。

6. 总结与扩展方向

通过这次从标量到SIMD，再到结合转置思维的矩阵乘法优化之旅，我们深刻体会到，性能优化是算法、数据布局和硬件特性的结合。对于游戏引擎开发，将核心数学库（向量、矩阵、四元数）进行SIMD优化，是提升整体性能的基石。

几个可以继续深入的方向：

1. 支持ARM Neon： 如果引擎要跨平台到iOS/Android，必须实现ARM架构的Neon SIMD版本。其intrinsics在<arm_neon.h>中，思想与SSE/AVX相通，但指令和寄存器名称不同。
2. 动态派发： 实现一个函数指针，在运行时根据cpuid检测到的CPU特性，绑定到最优的实现（标量、SSE4.2、AVX2、AVX-512）。
3. 与着色器的协同： 深入理解你的图形API（Vulkan/DirectX 12/WebGPU）的常量缓冲区布局要求，设计出既能高效CPU计算，又能直接上传GPU无需转换的矩阵存储格式。有时，为了匹配GPU的访问模式，在CPU端做一些转置或重排是值得的。
4. 扩展到仿射变换： 游戏中最常用的是4x3仿射变换矩阵（最后一行为[0,0,0,1]）。可以针对这种特殊情况实现更精简的SIMD乘法，节省一些运算。

最后，别忘了可读性和可维护性。将最优化版本的代码用清晰的函数和注释封装好，而将朴素的标量版本保留在DEBUG模式下，用于调试和验证正确性。毕竟，正确的慢代码远好过错误的快代码。在实际项目中，我通常会这样组织：

namespace Math { #if defined(USE_SIMD_AVX2) && defined(__AVX2__) // AVX2+FMAA实现 inline Matrix4 Multiply(const Matrix4& a, const Matrix4& b) { ... } #elif defined(USE_SIMD_SSE) && (defined(__SSE2__) || defined(_M_X64)) // SSE2实现 inline Matrix4 Multiply(const Matrix4& a, const Matrix4& b) { ... } #else // 标量后备实现 inline Matrix4 Multiply(const Matrix4& a, const Matrix4& b) { ... } #endif }

希望这篇长文能帮你打通游戏引擎中矩阵优化任督二脉。优化无止境，但每一次对底层的探索，都会让你对程序的理解更深一分。