跨平台浮点一致性

跨平台和交叉编译器的一致性当然是可能的.只要有足够的知识和时间,任何事都有可能!但它可能非常困难,或者非常耗时,或者确实不切实际.

以下是我可以预见的问题,没有特别的顺序:

请记住,即使是正负1/10 ^ 15的极小误差也可能会变得非常重要(您将该数字与该误差范围相乘10亿,现在您有一个加或减0.000001错误,可能很重要.)这些错误会在很多帧上累积,直到你有一个去同步的模拟.或者,当你比较值时,它们就会显现出来(即使在浮点比较中使用"epsilons"也是天真的,也可能没有帮助;只能取代或延迟表现.)

上述问题并不是分布式确定性模拟(如你的)所特有的.关于" 数值稳定性 " 问题的讨论,这是一个困难且经常被忽视的主题.

不同的编译器优化开关和不同的浮点行为确定开关可能导致编译器为相同的语句生成稍微不同的CPU指令序列.显然,使用完全相同的编译器,这些编译必须相同,否则生成的代码必须经过严格的比较和验证.

32位和64位程序(注意:我说的是程序而不是CPU)可能会表现出略微不同的浮点行为.默认情况下,32位程序不能依赖比CPU更高级的任何东西(没有SSE,SSE2,AVX等),除非您在编译器命令行中指定它(或使用ininsics/inline汇编指令)你的代码.)另一方面,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倍.即使是四舍五入,他们仍然不平等.你加剧了这个问题.

确实,这并没有发生太多,我给出的例子是两个不吉利的数字来处理这种情况,但仍然可以找到这些数字.当你这样做时,你就遇到了麻烦.唯一可靠的解决方案,即使您使用定点算术或其他任何方法,也要对所有可能的问题区域进行严格而系统的数学分析,并证明它们在各个程序中保持一致.

除此之外,对于我们凡人来说,你需要有一个防水的方式来监控情况,找到确切的时间和方式出现最轻微的差异,以便能够在事后解决问题(而不是依靠你的眼睛)查看游戏动画或对象移动或物理行为中的问题.)