为什么游戏不使用数学表达式模板？答案

【问题标题】：Why don't games use expression templates for math?为什么游戏不使用数学表达式模板？
【发布时间】：2019-11-08 10:53:21
【问题描述】：

我可以想象表达式模板在为向量/矩阵/四元数等普遍存在的事物编译时间方面做着可怕的事情，但如果它是一个如此巨大的速度提升，为什么游戏不使用它呢？很明显，SIMD 指令可以很好地利用数据级并行性。表达式模板和惰性求值结合起来似乎很有意义，至少在消除临时变量方面是这样。

因此，虽然像 Eigen 这样的库宣传此类功能，但我认为这在中间件（例如 Havok）或对速度至关重要的游戏中并不常见。任何人都可以对此有所了解吗？它与非确定性或分支预测有关吗？

【问题讨论】：

SIMD 与什么有什么关系？我没有看到那里的连接
SIMD 指令与表达式模板无关，惰性求值也无关。它也与非确定性或分支预测无关。这四件事中没有一件与表达式模板有任何关系。

标签： c++ templates optimization game-engine expression-templates

【解决方案1】：

我能想到很多原因：

它会影响编译时间。更长的编译时间意味着测试您对代码所做的任何更改需要更长的时间。这会损害生产力。
这很复杂。很可能团队中的许多开发人员不熟悉表达式模板，并且很难阅读和调试它们。
游戏通常必须在多个平台上运行，并且使用各种编译器，这些编译器可能存在各种缺点，例如，这可能会导致高级模板技巧问题。
通常没有必要。您可以编写高效的代码而无需表达式模板。它只会变得更加冗长，并且您必须为编译器做更多的事情。
游戏开发人员对 10 年前尚未在游戏中使用的任何东西都极为怀疑。不久前，几个主要的开发人员坚持使用 C：不是因为 C++ 不够好，而是因为它是“新的”。游戏开发者非常保守。

当然还有一个显而易见的问题：在哪里他们会使用表达式模板？是否有足够的复杂数学来真正使它值得？游戏往往依赖于相当少量的线性代数运算，通常在任何情况下都需要大量手动调整。

【讨论】：

10 年可能有点长，他们会变得更好；今年大多数主要版本都是使用 MSVC 2005 构建的。:P
我说的不仅仅是编译器版本，还有语言和语言特性的选择。可以使用现代 C++ 编译器编写 C 或类似 C 的类。

【解决方案2】：

我想再补充一个上述答案中未说明的原因。抱歉，我错过了。

向基于数学的类（例如 vec3 类）添加模板可能会改变运算符的含义，并导致函数对某些模板类型无效。

举个例子，

vec3<int> myVec( 3, 5, 4 );
myVec.Normalize();

标准化对于整数向量意味着什么？突然间，当我们将模板添加到数学结构时，我们会使许多现有函数无效，例如上面描述的示例。

另外，值得一提的是，许多数学结构都针对某些类型进行了优化，因为优化在游戏中非常重要。 GPU 是浮点计算机。 Doubles 占用了浮点数的两倍空间，并且计算起来相当慢，尽管对于新游戏开发者来说这似乎是一个明显的用例。

我希望这个例子有意义。模板是一个很好的工具，但游戏中的数学结构并不适合使用它们。

【讨论】：

【解决方案3】：

通常，游戏中对性能敏感且数学繁重且仍倾向于在 CPU 而非 GPU 上运行的部分会将相同的基本操作应用于大量元素。一些示例包括动画混合、物理计算、可见性测试等。

在当前控制台硬件上优化此类问题的最佳方法通常是尝试和批处理尽可能多的工作，并争取最大的数据局部性以避免代价高昂的缓存未命中。然后可以使用 SIMD 内在函数优化实际数学，并且通常会仔细手动优化。表达式模板为您提供的优化可以在手动优化阶段相对容易地执行，但也有可能执行表达式模板不会给您的各种其他重要优化。通常，这些关键代码会包含针对每个目标平台进行自定义优化的部分，并且移植性不强。

我认为表达式模板没有被广泛使用的原因是它们增加了软件复杂性（出于 jalf 描述的所有原因）到非性能关键代码中，这些代码并没有真正保证它，同时没有涵盖所有优化对于显示在配置文件顶部的真正对性能至关重要的代码是必需的。

【讨论】：

这在很大程度上是正确的，但随着计算着色器和 OpenCL 的变化而变化。许多物理计算，尤其是延迟请求，都利用了 GPU 卓越的浮点计算。