专栏首页程序猿石头一个由跨平台产生的浮点数bug | 有你意想不到的结果

一个由跨平台产生的浮点数bug | 有你意想不到的结果

本文为 6 年前的旧文整理重发,因为最开始是 workdpress 的程序,后改为静态 blog 过程中,导致格式等混乱,这篇年久失修旧文可文末点击原文访问。

问题背景

背景就简单点儿说,当初一个项目 C# 编写,涉及浮点运算,来龙去脉省去,直接看如下代码。(为什么有这个问题产生,是因为当初线上产生了很诡异的问题,和本地调试效果不一致。)

float p3x = 80838.0f;
float p2y = -2499.0f;
double v321 = p3x * p2y;
Console.WriteLine(v321);

很简单吧,马上笔算下结果为 -202014162,没问题,难道C#没有产生这样的结果?不可能吧,开启 VisualStudio,copy代码试试,果然结果是-202014162。就这样完了么?显然没有!把编译时的选项从AnyCPU改成x64试试~(服务器环境正是64位滴哦!!)结果居然变成了-202014160,对没错,就是-202014160。细想一下,因为浮点运算的误差,-202014160 这个结果是合理的。嗯,再试试C++。// 测试环境Intel(R) i7-3770 CPU, windows OS 64. Visual Studio 2012 默认设置。

float p3x = 80838.0f;
float p2y = -2499.0f;
double v321 = p3x * p2y;
std::cout.precision(15);
std::cout << v321 << std::endl;

呃,好像x86、x64都是这个合理的结果 -202014160。奇了个怪了。其实上面这段C++代码在不同的平台下的结果如下:

  • Windows 32/64位下:-202014160
  • Linux 64位下(CentOS 6 gcc 4.4.7):-202014160
  • Linux 32位下(Ubuntu 12.04+ gcc 4.6.3)是:-202014162

合理的运算结果,应该是-202014160,正确的运算结果是-202014162,合理性是浮点精度不够造成的(后文解释了合理性)。若是用两个double相乘可得正确且合理的运算结果。// 就别纠结我用的“正确、合理”这两个词是否恰当了。问题是为何C#下X64和X86结果不一致?

浮点运算结果错误但合理的解释

为何 80838.0f * -2499.0f = -202014160.0 是合理的?

32位浮点数在计算机中的表示方式为:1位符号位(s)-8位指数位(E)-23位有效数字(M),即:

其中E是实际转换成1.xxxxx*2^E的指数,M是去掉 1 后的前面的xxxxx(节约1位)。

1. 80838.0 如何表达?

80838.0 = 1 0011 1011 1100 0110.0(二进制) = 1.0011 1011 1100 0110 0*2^16

有效位M = 0011 1011 1100 0110 0000 000(一共 23 位)

指数位E = 16 + 127 = 143 = 10001111

内部表示 80838.0 = 0 [10001111] [0011 1011 1100 0110 0000 000] = 0100 0111 1001 1101 1110 0011 0000 0000 = 47 9d e3 00 //实际调试时看到的内存值 可能是00 e3 9d 47是因为调试环境用了小端表示法法:低位字节排内存低地址端,高位排内存高地址

2. -2499.0 如何表达?

-2499.0 = -100111000011.0 = -1.001110000110 * 2^11

有效位M = 0011 1000 0110 0000 0000 000

指数位E = 11+127=138= 10001010

符号位s = 1

内部表示-2499.0 = 1 [10001010] [0011 1000 0110 0000 0000 000]

=1100 0101 0001 1100 0011 0000 0000 0000 =c5 1c 30 00

3. 如何计算 80838.0 * -2499.0 = ?

指数 e = 11+16 = 27

则指数位 E = e + 127 = 154 = 10011010

有效位相乘结果为 1.1000 0001 0100 1111 1011 1010 01 (可以自己动手实际算下),实际中只能有23位,后面的被截断即1000 0001 0100 1111 1011 1010 01,相乘结果内部表示=1[10011010][1000 0001 0100 1111 1011 101] = 1100 1101 0100 0000 1010 0111 1101 1101 = cd 40 a7 dd

结果 = -1.1000 0001 0100 1111 1011 101 *2^27

= -11000 0001 0100 1111 1011 1010000

= -202014160

通过上面得知,32 位浮点数,-202014160 就是合理的结果,完全能解释清楚。但如果有效数字更长的话, 上面的就不会被截断。

4. 正确的结果-202014162怎么得来?

有效位相乘结果为 1.1000 0001 0100 1111 1011 1010 01

即结果 = -1.1000 0001 0100 1111 1011 101001 *2^27

= -11000 0001 0100 1111 1011 101001 = -202014162

根因挖掘

上面部分解释了两种结果的来源,但貌似没从根本回到为什么?用C++同样的代码,X86,X64(DEBUG下,这个后面会说)下得到一致的结果-202014160,容易理解且也是合理的。原因何在?看下编译后生成的代码(截取关键部分)

//C# x86 下
......
float p3x = 80838.0f;
0000003b mov dword ptr [ebp-40h],479DE300h
float p2y = -2499.0f;
00000042  mov dword ptr [ebp-44h],0C51C3000h
double v321 = p3x * p2y;
00000049  fld dword ptr [ebp-40h]
0000004c fmul dword ptr [ebp-44h]
0000004f  fstp qword ptr [ebp-4Ch]
.......

//C# X64下
......
float p3x = 80838.0f;
00000045  movss xmm0,dword ptr [00000098h]
0000004d  movss dword ptr [rbp+3Ch],xmm0
float p2y = -2499.0f;
00000052  movss xmm0,dword ptr [000000A0h]
0000005a movss dword ptr [rbp+38h],xmm0
double v321 = p3x * p2y;
0000005f  movss xmm0,dword ptr [rbp+38h]
00000064  mulss xmm0,dword ptr [rbp+3Ch]
00000069  cvtss2sd xmm0,xmm0
0000006d  movsd mmword ptr [rbp+30h],xmm0
......

C++ x86 / x64下都生成了类似的代码(这也就是为何 C++ x86/x64与C#x64结果一致)即都用了先用浮点乘起来(mulss),然后转成double(cvtss2sd)。从上面的汇编代码可以看出 C# X86生成代码用的指令fld/fmul/fstp等。其中fld/fmul/fstp等指令是由FPU(float point unit)浮点运算处理器做的,FPU在进行浮点运算时,用了80位的寄存器做相关浮点运算,然后再根据是float/double截取成32位或64位。非FPU的情况是用了SSE中128位寄存器(float实际只用了其中的32位,计算时也是以32位计算的),这就是导致上述问题产生的最终原因。

浮点运算标准IEEE-754 推荐标准实现者提供浮点可扩展精度格式(Extended precision),Intel x86处理器有FPU(float point unit)浮点运算处理器支持这种扩展。C#的浮点是支持该标准的,其中其官方文档也提到了浮点运算可能会产生比返回类型更高精度的值(正如上面的返回值精度就超过了float的精度),并说明如果硬件支持可扩展浮点精度的话,那么所有的浮点运算都将用此精度进行以提高效率,举个例子x*y/z, x*y的值可能都在double的能力范围之外了,但真实情况可能除以z后又能把结果拉回到double范围内,这样的话,用了FPU的结果就会得到一个准确的double值,而非FPU的就是无穷大之类的了。

即产生如上的结果原因是,两个浮点数相乘在非FPU的情况下,用了32位计算产生的结果导致结果存在误差,而FPU是用了80位进行计算的,所以得到的结果是精度很高的,体现在本文的案例上就是个位数上的2。所以大家在写代码的时候得保证实际运行环境/测试环境/开发环境的一致性(包括OS架构啊、编译选项等)啊,不然莫名其妙的问题会产生(本文就是开发环境与运行环境不一致导致的问题,纠结了好久才发现是这个原因);遇到涉及浮点运算的时候别忘了有可能是这个原因产生的;另外,float/double混用的情况得特别注意。

总结一下,本文通过分析之前遇到的一个疑难杂症带着大家一块回顾或者学习了一下计算机内部浮点数的表达,解决了疑问。有时候可能需要跟进到硬件底层,当然随着硬件技术的发展,可能以前理所当然的东西在新硬件的情况下也会有所不同。

本文分享自微信公众号 - 程序猿石头(tangleithu),作者:码农唐磊

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-05-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 性能测试工具 - ab 简单应用

    之前知道一般网站性能可以通过 LoadRunner, JMeter, QTP 等相应的软件进行测试, 印象中本科学习 “软件测试” 这门课程时安装并使用过, L...

    程序猿石头
  • 性能测试工具 - ab

    之前知道一般网站性能可以通过 LoadRunner, JMeter, QTP 等相应的软件进行测试, 印象中本科学习 “软件测试” 这门课程时安装并使用过, L...

    程序猿石头
  • 腾讯云服务器, 域名备案及 CDN 服务体验

    另外, 程序猿有个自己稳定的网络开发环境(程序猿开发不都是 copy from stackoverflow/Google 么, 哈哈 ?)也是极好的. 所以最终...

    程序猿石头
  • 开发高质量的软件要付出什么样的代价?

    在软件开发项目中,常见的争论之一是花费时间来提高软件质量,还是集中精力发布更有价值的功能。通常来说,交付功能的压力占据了主导地位,许多开发人员因此抱怨他们没有时...

    Java帮帮
  • 4月深圳创新大会,腾讯,淘宝,京东等16位创新探索者都来了,等你赴约

    2018年,我们走过了北上广深杭、成都、厦门、南京等十多个城市,邀请了上百位来自腾讯、阿里、网易、美团点评、饿了么、小米、快手、携程、京东、爱奇艺、滴滴、美图...

    腾讯大讲堂
  • “无人店”热潮平息,“机器视觉+商业智能”以另类模式落地传统零售 | 活动

    走进一家便利店,随即响起提示音:“您好,会员,欢迎光临,今天XXX商品有打折哦。”

    镁客网
  • 10个梯度下降优化算法+备忘单

    梯度下降是一种寻找函数极小值的优化方法,在深度学习模型中常常用来在反向传播过程中更新神经网络的权值。

    AI研习社
  • 发布AI芯片昆仑和百度大脑3.0、L4自动驾驶巴士量产下线,这是百度All in AI一年后的最新答卷

    首先亮相的是百度创始人、董事长兼首席执行官李彦宏。在大会的主 Keynote 环节中,李彦宏介宣布,全球首款 L4 级自动驾驶巴士量产下线。此自动驾驶巴士由百度...

    机器之心
  • 曾经跨过山和大海的百度AI技术汇,跨进北工大!

    开场前半分钟,北京工业大学的三名信息技术专业大二学生气吁吁地赶到了科技楼的会议厅。环顾四周,竟座无虚席。他们干脆拿出笔记本站在会议厅后排,和现场近百名同学一起投...

    用户1386409
  • 可以旋转的3D韦恩图你见过吗?

    韦恩图是一种在科研文章中非常常见的图示法,比如在转录组数据中,常常会涉及到几千甚至上万的基因数量,有时为了研究需要,会分别获得两组或多组数据中具有某种特定功能或...

    百味科研芝士

扫码关注云+社区

领取腾讯云代金券