无论是否在调试器下运行，我都在使用调试版本并在同一台机器上获得不同的结果。我正在使用优秀的 TestDriven.Net 来运行单元测试。
- 使用 TestDriven.Net 或外部 NUnit 运行器“运行”产生相同的结果
- “使用调试器运行”与 TestDriven.Net 产生不同的结果
代码是
- 复杂的迭代网格变形例程涉及浮点精度极限的大量计算
- 针对 .Net 3.5 的 C#、VS2012。
- 单线程
- 仅调试构建，未构建发布版本
- 同一台机器，没有节能\speedstep 或我知道的其他功能
- Vanilla C# - 没有不安全代码、非托管库、平台调用等。
- 没有调试器检查代码或奇怪的第三方库
我没有回溯到第一个差异(没有调试器会很棘手!)但考虑到代码的迭代程度，它的输入敏感度和最微小的差异将在足够的时间增长到显着的比例。
我知道跨编译器、平台和体系结构的 fp 可重现性是多么脆弱，但失望地发现调试器是导致失败的因素之一。
我是必须接受这个事实，还是您可以提供任何建议？
最佳答案
Do I have just have to accept this as a fact of life or is there any advice you can offer?
你必须接受它作为生活中的事实。浮点代码可以在不同情况下进行不同的优化。特别是，在某些情况下，JIT 编译器可以使用具有更高精度/准确性(例如 80 位浮点)的表示来进行操作。 JIT 编译器执行此操作的情况取决于体系结构、优化设置等。关于您对变量(以及它是否为局部变量)所做的操作，可能存在许多微妙之处，这些都会影响这一点。在调试器下运行通常会非常显着地影响 JIT 优化设置 - 不仅仅是 float - 所以我对此并不感到惊讶。
如果您执行具有一定容差的浮点比较，应该没问题 - 无论如何，精确 对浮点类型进行相等比较很少是个好主意。当然，您实际上可能正在执行差异变得显着的非平等比较，但我很少遇到这个问题。
关于c# - 浮点差异取决于调试构建的运行方式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18417899/