现代计算系统的某些方面本质上是不确定的，可能会导致这些差异。只要与解决方案所需的精度相比差异非常小，就可能没有任何理由担心这一点。

根据我自己的经验，一个可能出错的例子。考虑计算两个向量 x 和 y 的点积的问题。

$d=\sum_{i=1}^{n} x_{i}y_{i}$

计算这个点积需要计算乘积，然后将结果相加。浮点乘法每次都应该产生完全相同的结果。如果每次都以相同的顺序计算浮点加法，则总和应该相同。但是，由于浮点加法不是关联的，如果以不同顺序执行加法的方式计算两个向量的乘积，您可能会得到不同的结果。 $x_{i}y_{i}$

例如，您可能首先计算两个向量的乘积为

$d=((x_{1}y_{1})+(x_{2}y_{2}))+(x_{3}y_{3})$

然后作为

$d=(x_{1}y_{1})+((x_{2}y_{2})+(x_{3}y_{3}))$。

这怎么可能发生？这里有两种可能性。

1. 并行内核上的多线程计算。现代计算机通常具有 2、4、8 甚至更多可以并行工作的处理器内核。如果您的代码使用并行线程在多个处理器上计算点积，那么系统的任何随机扰动（例如，用户移动他的鼠标并且其中一个处理器内核必须在返回到点积之前处理该鼠标移动）都可能导致添加顺序发生变化。

2. 数据和向量指令的对齐。现代英特尔处理器具有一组特殊的指令，可以一次操作（例如）浮点数。如果数据在 16 字节边界上对齐，则这些向量指令效果最佳。通常，点积循环会将数据分成 16 个字节的部分（一次 4 个浮点数）。如果再次运行代码，则数据可能与 16 字节的内存块对齐方式不同，因此添加的内容是以不同的顺序执行，导致不同的答案。

您可以通过使您的代码作为单线程运行并禁用所有并行处理来解决第 1 点。您可以通过要求内存分配来对齐内存块来解决第 2 点（通常，您可以通过使用 -align 之类的开关编译代码来做到这一点。）如果您的代码仍然给出不同的结果，那么还有其他可能性可以查看在。

来自英特尔的这份文档讨论了可能导致使用英特尔数学核心函数库的结果不可重现的问题。 英特尔的另一份文档讨论了与英特尔编译器一起使用的编译器开关。

提到的 FFTW 库可能以非确定性模式运行。

如果您使用 FFTW_MEASURE 或 FFTW_PATIENT 模式，程序会在运行时检查哪些参数值工作最快，然后将在整个程序中使用这些参数。因为运行时间明显会有一点波动，所以参数会有所不同，傅里叶变换的结果将是不确定的。如果您想要确定性 FFTW，请使用模式 FFTW_ESTIMATE。

虽然由于多核/多线程处理场景很可能会发生表达式术语评估顺序的更改，但不要忘记可能存在（尽管这是一个很长的镜头）某种硬件设计缺陷在起作用。还记得 Pentium FDIV 问题吗？（参见https://en.wikipedia.org/wiki/Pentium_FDIV_bug）。前段时间，我从事基于 pc 的模拟电路仿真软件。我们的方法的一部分涉及开发回归测试套件，我们将针对软件的夜间构建运行这些套件。对于我们开发的许多模型，迭代方法（例如 Newton-Raphson ( https://en.wikipedia.org/wiki/Newton%27s_method) 和 Runge-Kutta) 被广泛用于仿真算法。对于模拟设备，通常会出现具有极小数值的内部伪影，例如电压、电流等。作为模拟过程的一部分，这些值随着（模拟的）时间递增地变化。这些变化的幅度可能非常小，我们经常观察到的是，后续 FPU 对此类 delta 值的操作接近于 FPU 精度的“噪声”阈值（64 位浮点数具有 53 位尾数，IIRC）。再加上我们经常不得不在模型中引入“PrintF”日志代码以允许调试（啊，好日子！），实际上保证了每天都有零星的结果！所以呢' 这一切意味着什么？您必须期望在这种情况下看到差异，最好的办法是定义和实施一种方法来决定（幅度、频率、趋势等）何时/如何忽略它们。

虽然异步操作的浮点舍入可能是问题，但我怀疑它更平庸。使用未初始化的变量会为您的其他确定性代码添加随机性。这是一个经常被开发人员忽略的常见问题，因为当您在调试模式下运行时，所有变量在声明时都被初始化为 0。当不在调试模式下运行时，分配给变量的内存具有分配之前内存的任何值。作为优化，内存不会在分配时归零。如果这发生在您的代码中，则很容易修复，而在库代码中则更少。