本文从一个有趣而诡异的实验开始。最先这个例子博主是从 Stackoverflow上的一个问题中看到的。为了提升可读性,博主这里作了改写,简化成了如下两段代码:html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
#include <iostream>
#include <string>
using
namespace
std;
int
main() {
const
float
x=1.1;
const
float
z=1.123;
float
y=x;
for
(
int
j=0;j<90000000;j++)
{
y*=x;
y/=z;
y+=0.1f;
y-=0.1f;
}
return
0;
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
#include <iostream>
#include <string>
using
namespace
std;
int
main() {
const
float
x=1.1;
const
float
z=1.123;
float
y=x;
for
(
int
j=0;j<90000000;j++)
{
y*=x;
y/=z;
y+=0;
y-=0;
}
return
0;
}
|
上面两段代码的惟一差异就是第一段代码中y+=0.1f,而第二段代码中是y+=0。因为y会先加后减一样一个数值,照理说这两段代码的做用和效率应该是彻底同样的,固然也是没有任何逻辑意义的。假设如今我告诉你:其中一段代码的效率要比另外一段慢7倍。想必读者会认为必定是y+=0.1f的那段慢,毕竟它和y+=0相比看上去要多一些运算。可是,实验结果,却出乎意料, y+=0的那段代码比y+=0.1f足足慢了7倍。 。世界观被颠覆了有木有?博主是在本身的Macbook Pro上进行的测试,有兴趣的读者也能够在本身的笔记本上试试。(只要是支持SSE2指令集的CPU都会有类似的结果)。ios
1
2
3
4
5
6
7
8
9
10
11
12
13
|
shell> g++ code1.c -o test1
shell> g++ code2.c -o test2
shell>
time
./test1
real 0m1.490s
user 0m1.483s
sys 0m0.003s
shell>
time
./test2
real 0m9.895s
user 0m9.871s
sys 0m0.009s
|
固然 原文中的投票最高的回答解释的很是好,但博主第一次看的时候是一头雾水,由于大部分基础知识已经还给大学老师了。因此,本着知其然还要知其因此然的态度,博主作了一个详尽的分析和思路整理过程。也但愿读者可以从0开始解释这个诡异现象的缘由。shell
如今让咱们复习大学计算机基础课程。若是你熟练掌握了浮点数向二进制表达式转换的方法,那么你能够跳过这节。
咱们先来看下浮点数二进制表达的三个组成部分。ide
三个主要成分是:工具
下面咱们来看个实际例子来解释下转换过程。
Step 1 改写整数部分
以数值5.2为例。先不考虑指数部分,咱们先单纯的将十进制数改写成二进制。
整数部分很简单,5.即101.。性能
Step 2 改写小数部分
小数部分咱们至关于拆成是2^-1一直到2^-N的和。例如:
0.2 = 0.125+0.0625+0.007825+0.00390625即2^-3+2^-4+2^-7+2^-8….,也即.00110011001100110011测试
Step 3 规格化
如今咱们已经有了这么一串二进制101.00110011001100110011。而后咱们要将它规格化,也叫Normalize。其实原理很简单就是保证小数点前只有一个bit。因而咱们就获得了如下表示:1.0100110011001100110011 * 2^2。到此为止咱们已经把改写工做完成,接下来就是要把bit填充到三个组成部分中去了。编码
Step 4 填充
指数部分(Exponent):以前说过须要以127做为偏移量调整。所以2的2次方,指数部分偏移成2+127即129,表示成10000001填入。
整数部分(Mantissa):除了简单的填入外,须要特别解释的地方是1.010011中的整数部分1在填充时被舍去了。由于规格化后的数值整部部分老是为1。那你们可能有疑问了,省略整数部分后岂不是1.010011和0.010011就混淆了么?其实并不会,若是你仔细看下后者:会发现他并非一个规格化的二进制,能够改写成1.0011 * 2^-2。因此省略小数点前的一个bit不会形成任何两个浮点数的混淆。
具体填充后的结果见下图spa
练习:若是想考验本身是否充分理解这节内容的话,能够随便写一个浮点数尝试转换。经过 浮点二进制转换工具能够验证答案。.net
了解完浮点数的表达之后,不难看出浮点数的精度和指数范围有很大关系。最低不能低过2^-7-1最高不能高过2^8-1(其中剔除了指数部分全0喝全1的特殊状况)。若是超出表达范围那么不得不舍弃末尾的那些小数,咱们成为overflow和underflow。甚至有时舍弃都没法表示,例如当咱们要表示一个:1.00001111*2^-7这样的超小数值的时候就没法用规格化数值表示,若是不想点其余办法的话,CPU内部就只能把它当作0来处理。那么,这样作有什么问题呢?最显然易见的一种反作用就是:当屡次作低精度浮点数舍弃的后,就会出现除数为0的exception,致使异常。固然精度失准严重起来也能够要人命,如下这个事件摘自wikipedia
On 25 February 1991, a loss of significance in a MIM-104 Patriot missile battery prevented it intercepting an incoming Scud missile in Dhahran, Saudi Arabia, contributing to the death of 28 soldiers from the U.S. Army’s 14th Quartermaster Detachment.[25] See also: Failure at Dhahran
因而乎就出现了Denormalized Number(后称非规格化浮点)。他和规格浮点的区别在于,规格浮点约定小数点前一位默认是1。而非规格浮点约定小数点前一位能够为0,这样小数精度就至关于多了最多2^22范围。
可是,精度的提高是有代价的。因为CPU硬件只支持,或者默认对一个32bit的二进制使用规格化解码。所以须要支持32bit非规格数值的转码和计算的话,须要额外的编码标识,也就是须要额外的硬件或者软件层面的支持。如下是wiki上的两端摘抄,说明了非规格化计算的效率很是低。> 通常来讲,由软件对非规格化浮点数进行处理将带来极大的性能损失,而由硬件处理的状况会稍好一些,但在多数现代处理器上这样的操做还是缓慢的。极端状况下,规格化浮点数操做可能比硬件支持的非规格化浮点数操做快100倍。
For example when using NVIDIA’s CUDA platform, on gaming cards, calculations with double precision take 3 to 24 times longer to complete than calculations using single precision.
若是要解释为何有如此大的性能损耗,那就要须要涉及电路设计了,超出了博主的知识范围。固然万能的wiki也是有答案的,有兴趣的读者能够自行查阅。
总上面的分析中咱们得出了如下结论:
因而咱们就能够发现经过几十上百次的循环后,y中存放的数值无限接近于零。CPU将他表示为精度更高的非规格化浮点。而当y+0.1f时为了保留跟重要的底数部分,以后无限接近0(也即y以前存的数值)被舍弃,当y-0.1f后,y又退化为了规格化浮点数。而且以后的每次y*x和y/z时,CPU都执行的是规划化浮点运算。
而当y+0,因为加上0值后的y仍然能够被表示为非规格化浮点,所以整个循环的四次运算中CPU都会使用非规格浮点计算,效率就大大下降了。
固然,也有在程序内部也是有办法控制非规范化浮点的使用的。在相关程序的上下文中加上fesetenv(FE_DFL_DISABLE_SSE_DENORMS_ENV);就能够迫使CPU放弃使用非规范化浮点计算,提升性能。咱们用这种办法修改上面实验中的代码后,y+=0的效率就和y+=0.1f就同样了。甚至还比y+=0.1f更快了些,世界观又端正了不是么:) 修改后的代码以下
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
#include <iostream>
#include <string>
#include <fenv.h>
using
namespace
std;
int
main() {
fesetenv(FE_DFL_DISABLE_SSE_DENORMS_ENV);
const
float
x=1.1;
const
float
z=1.123;
float
y=x;
for
(
int
j=0;j<90000000;j++)
{
y*=x;
y/=z;
y+=0;
y-=0;
}
return
0;
}
|