我查看了您的简单代码示例，我怀疑您观察到的速度损失是由于 C 传统要求使用中间双精度运算来评估右侧表达式，即使源变量是单一的精度和输出位置（左侧目的地）是单精度。

这样做的目的是避免中间计算中的准确性损失，但如果程序员没有意识到这一点，只需像您所做的那样更改类型将导致在每个源变量上从 float 到 double 以及在存储左评估结果。

在您的矩阵乘法代码中，浮点计算显示为嵌套循环中的一行，因此四个生成的类型转换可能很容易与双精度“中间”值的一次乘法和一次加法的时间成本进行比较。

FLT_EVAL_METHOD自 C++ 11 以来，头文件中有一个标准的“定义” ，<cfloat>它公开了一个依赖于实现的参数，以反映中间表达式评估所需的额外精度（如果有的话） 。乍一看，人们可能希望FLT_EVAL_METHOD0 意味着不会进行不必要的转换或提升，但仔细阅读会发现，总是允许“计算就像所有中间结果具有无限范围和精度一样”。出于这个原因，我不会将该参数视为降低精度的保证。

最好的办法是查看生成的汇编语言文件，了解编译器插入浮点转换的频率。稍后我将尝试使用您的示例代码来说明这一点。

有多种可能的解释：

• 由于floats 和doubles 的计算次数不同，例如，迭代次数/函数评估次数（或其他原因，正如@Richard 在评论中指出的那样）
• 有一些类型转换/实现（比如模板化代码）对于float类型不是最优的，而不是doubles。我曾经在过度专业化模板实现时遇到过这个问题。
• C++ 标准库可以根据类型特征为标准算法选择不同的路径。我遇到的一个最近的例子：排序算法double和我的自定义实现complex<double>，由于我有一个非平凡的构造函数，快速排序算法切换到合并排序的方式比“简单数据类型”要晚。但是，此类事情通常会受益于较小的 32 位数据类型。

SIMD 不太可能double比 for更有效float，除非您在一些具有异国情调的编译器的奇异架构上运行。相反，现在的趋势是针对单精度甚至半精度（深度学习的影响）进行优化，而不是double和quad。

要尝试的事情：

• 检查我在上面这个答案中触及的明显项目
• 最小的可重现示例（正如@Richard 指出的那样）
• Godbolt在最小可重现示例上查看发生了什么