跨平台和跨编译器的一致性当然是可能的。只要有足够的知识和时间，一切皆有可能！但这可能非常困难，或者非常耗时，或者实际上是不切实际的。
以下是我可以预见的问题，没有特别的顺序：
请记住，即使是很小的正负1/10 ^ 15的误差也可能会变得很大（将这个数字乘以十亿的误差幅度，现在您将有正负0.000001的误差，这些错误可能会随着时间，在许多帧上累积，直到您出现不同步的仿真为止。或者它们可以在您比较值时显示（即使在浮点比较中天真地使用“ epsilons”也可能无济于事；仅替换或延迟显示）。
上面的问题并不是分布式确定性仿真所独有的（像您一样）。关于“ 数值稳定性 ” 的问题，这是一个困难且经常被忽略的主题。
不同的编译器优化开关和不同的浮点行为确定开关可能导致编译器为相同的语句生成稍微不同的cpu指令序列。显然，在所有编译中，使用完全相同的编译器，它们必须相同，或者必须严格比较和验证生成的代码。
32位和64位程序（注意：我是说程序而不是cpu）可能会表现出稍微不同的浮点行为。默认情况下，除非您在编译器命令行上指定（或使用以下命令中的内在函数/内联汇编指令），否则32位程序不能依赖比cpu的x87指令集更高级的内容（无SSE，SSE2，AVX等）。另一方面，可以保证64位程序可以在具有SSE2支持的cpu上运行，因此，编译器将默认使用这些指令（同样，除非被用户覆盖）。x87和SSE2浮点数据类型时。并且它们的操作类似，它们是-AFAIK-不相同。如果一个程序使用一个指令集而另一程序使用另一个指令集，则会导致仿真不一致。
x87指令集包括一个“控制字”寄存器，其中包含一些标志，这些标志控制浮点运算的某些方面（例如，精确的舍入行为等）。这是运行时的事情，您的程序可以执行一组计算，然后更改该寄存器，然后执行完全相同的计算并获得不同的结果。显然，必须检查和处理该寄存器，并在不同的机器上保持相同。编译器（或您在程序中使用的库）可能会生成代码，这些代码会在运行时在整个程序中不一致地更改这些标志。
同样，在使用x87指令集的情况下，英特尔和AMD历来在实现方面有所不同。例如，一个供应商的cpu可能在内部使用比另一个供应商更多的位进行一些计算（因此得出的结果更准确），这意味着如果您碰巧在两个不同供应商的两个不同cpu（均为x86）上运行，则简单计算的结果 可能 会不同。我不知道如何以及在什么情况下可以启用这些更高的精度计算，以及它们是否在正常运行条件下发生，还是您必须专门询问，但我确实知道这些差异存在。
随机数以及在程序之间一致且确定地生成它们与浮点一致性无关。它很重要，并且是许多错误的源头，但最后，您只需要保持更多状态就可以同步。
以下是一些可能会有所帮助的技术：
一些项目使用“ 定点 ”数字和定点算法来避免舍入误差和浮点数的一般不可预测性。阅读Wikipedia文章以获取更多信息和外部链接。
在我自己的一个项目中，在开发过程中，我曾经对游戏所有实例中的所有相关状态（包括很多浮点数）进行哈希处理，并在每一帧通过网络发送哈希值，以确保均匀这种状态在不同的机器上没有什么不同。这也有助于进行调试，而不是让我不敢看我的眼睛去查看何时何地存在不一致（无论如何也不会告诉我它们起源于何处），我会立即知道在一台机器上游戏状态的某些部分开始发散从其他对象，并确切地知道它是什么（如果哈希检查失败，我将停止模拟并开始比较整个状态。） 此功能从一开始就在该代码库中实现，并且仅在开发过程中用于帮助调试（因为它具有性能和内存成本）。
（回答下面的第一条评论）：正如我在第1点中所说的，其他人在其他答案中所说的那样，这并不能保证任何事情。如果这样做， 可能会 降低发生不一致的可能性和频率，但是可能性不会变为零。如果您不仔细，系统地分析代码中正在发生的事情以及可能的问题根源，那么无论您“舍入”多少数字，仍然有可能遇到错误。
例如，如果您有两个数字（例如，应该产生相同结果的两个计算结果），分别为1.111499999和1.111500001，并将它们四舍五入到小数点后三位，则它们分别变为1.111和1.112。原始数字的差异仅为2E-9，但现在变成1E-3。实际上，您已将错误增加了500‘000次。即使四舍五入，它们仍然不相等。您加剧了这个问题。
没错，这种情况发生得并不多，我给出的示例是在这种情况下遇到的两个不幸数字，但是仍然可以用这些数字找到自己。而当您这样做时，您就会遇到麻烦。即使您使用定点算术或其他方法，唯一可行的解??决方案是对所有可能出现的问题区域进行严格而系统的数学分析，并证明它们在整个程序中将保持一致。
简而言之，对于我们这些凡人，您需要有一种不透水的方式来监控情况，并准确地发现何时以及如何出现最小的差异，以便事后解决问题（而不是依靠您的眼睛）以查看游戏动画或对象移动或身体行为方面的问题。）
602392714
清零编程群