.NET Math.Log10() 在不同机器上的行为不同
我发现在机器 A 上运行
Math.Log10(double.Epsilon)
将返回大约 -324
,但在机器 B 上将返回 -Infinity
。
它们最初的行为方式相同,返回 -324< /代码>。
两台计算机最初都使用相同的操作系统 (WinXP SP3) 和 .NET 版本 (3.5 SP1)。计算机 B 上可能有 Windows 更新,但除此之外没有发生任何更改。
什么可以解释行为的差异?
评论中讨论的更多详细信息:
- 机器 A CPU 是 32 位 Intel Core Duo T2500 2 GHz
- 机器 B CPU 是 32 位 Intel P4 2.4 GHz
- 从使用多个第三方组件的大型应用程序中运行的代码中收集的结果。但是,两台计算机上都运行相同的 .exe 和组件版本。
- 在机器 B 上的简单控制台应用程序中打印
Math.Log10(double.Epsilon)
会打印-324
,而不是-Infinity
- FPU 控制字两台机器始终为
0x9001F
(使用_controlfp()
读取)。
更新:最后一点(FPU 控制字)不再正确:使用较新版本的 _controlfp() 显示了不同的控制字,这解释了不一致的行为。 (有关详细信息,请参阅下面 rsbarro 的回答。)
I found that running
Math.Log10(double.Epsilon)
will return about -324
on machine A, but will return -Infinity
on machine B.
They originally behaved the same way by returning -324
.
Both machines started out using the same OS (WinXP SP3) and .NET version (3.5 SP1). There may have been Windows updates on machine B, but otherwise no changes are known to have happened.
What could explain the difference in behavior?
More details from discussions in comments:
- Machine A CPU is a 32-bit Intel Core Duo T2500 2 GHz
- Machine B CPU is a 32-bit Intel P4 2.4 GHz
- Results collected from code running in a large application using several 3rd party components. However, same .exe and component versions are running on both machines.
- Printing
Math.Log10(double.Epsilon)
in a simple console application on machine B prints-324
, NOT-Infinity
- The FPU control word on both machines is always
0x9001F
(read with_controlfp()
).
UPDATE: The last point (FPU control word) is no longer true: Using a newer version of _controlfp() revealed different control words, which explains the inconsistent behavior. (See rsbarro's answer below for details.)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
根据 @CodeInChaos 和 @Alexandre C 的评论,我能够组合一些代码以在我的 PC(Win7 x64、.NET 4.0)上重现该问题。此问题似乎是由于可以使用 _controlfp_s。 double.Epsilon 的值在两种情况下相同,但当非正规控制从 SAVE 切换到 FLUSH 时,其计算方式会发生变化。
以下是示例代码:
有几点需要注意。首先,我必须在
ControlFPS
声明上指定CallingConvention = CallingConvention.Cdecl
以避免在调试时出现不平衡堆栈异常。其次,我不得不求助于不安全的代码来检索GetCurrentControlWord()
中控制字的值。如果有人知道编写该方法的更好方法,请告诉我。以下是输出:
要确定机器 A 和机器 B 发生了什么,您可以使用上面的示例应用程序并在每台机器上运行它。我想您会发现:
如果您有机会在每个机器上尝试示例应用程序,机器,请用结果更新评论。我有兴趣看看会发生什么。
Based on the comments by @CodeInChaos and @Alexandre C, I was able to throw together some code to reproduce the issue on my PC (Win7 x64, .NET 4.0). It appears this issue is due to the denormal control that can be set using _controlfp_s. The value of double.Epsilon is the same in both cases, but the way it is evaluated changes when the denormal control is switched from SAVE to FLUSH.
Here is the sample code:
A couple things to note. First, I had to specify
CallingConvention = CallingConvention.Cdecl
on theControlFPS
declaration to avoid getting an unbalanced stack exception while debugging. Second, I had to resort to unsafe code to retrieve the value of the control word inGetCurrentControlWord()
. If anyone knows of a better way to write that method, please let me know.Here is the output:
To determine what is going on with machine A and machine B, you could take the sample app above and run it on each machine. I think you're going to find that either:
If you get a chance to try out the sample app on each machine, please update the comments with the results. I'm interested to see what happens.
进程中加载的 dll 可能会扰乱 x87 浮点标志。 DirectX/OpenGL 相关库因此而臭名昭著。
jitted 代码中也可能存在差异(不要求浮点在 .net 中以特定方式运行),但这不太可能,因为您使用相同的 .net 和操作系统版本。
在 .net 中,常量被嵌入到调用代码中,因此
double.Epsilons
之间不应该有任何差异。It's possible that a dll was loaded into the process that messed with the x87 floating-point flags. DirectX/OpenGL related libraries are notorious for this.
There could also be differences in the jitted code(There is no requirement for floating points to behave a specific way in .net), but that's very unlikely since you use the same .net and OS version.
In .net constants get baked into the calling code, so there should be no differences between the
double.Epsilons
.