【问题标题】:Do any real-world CPUs not use IEEE 754?是否有任何真实世界的 CPU 不使用 IEEE 754?
【发布时间】:2011-01-15 02:56:35
【问题描述】:

我正在优化数字/统计库的排序函数,基于这样的假设,在过滤掉任何 NaN 并进行一些操作后,浮点数可以在不改变结果的情况下与 32 位整数进行比较,而双精度数可以比较为 64 位整数。

这似乎将这些数组的排序速度提高了 40% 左右,只要浮点数的位级表示是 IEEE 754,我的假设就成立。人们实际上是否有任何现实世界的 CPU使用(不包括在此库不针对的嵌入式设备中)使用可能会破坏此假设的其他表示?


【问题讨论】:

  • 非常有趣 - 您能否详细说明如何将它们作为整数进行比较?
  • 请注意,您可能还假设整数 endian = FP endian,这在大多数(所有?)“正常”CPU 上都是正确的,但至少在理论上它们可能会有所不同在符合 IEEE754 的机器上。

标签: performance sorting floating-point ieee-754


【解决方案1】:

除了flawed Pentiums,任何基于 x86 或 x64 的 CPU 都使用 IEEE 754 作为其浮点算术标准。

这里简要概述了 FPA 标准及其采用情况。

IEEE 754:       Intel x86, and all RISC systems (IBM Power
                and PowerPC, Compaq/DEC Alpha, HP PA-RISC,
                Motorola 68xxx and 88xxx, SGI (MIPS) R-xxxx,
                Sun SPARC, and others);

VAX:            Compaq/DEC

IBM S/390:      IBM (however, in 1998, IBM added an IEEE 754
                option to S/390)

Cray:           X-MP, Y-MP, C-90; other Cray models have been
                based on Alpha and SPARC processors with
                IEEE-754 arithmetic.

除非您计划在相当奇特的 CPU 架构上支持您的库,否则可以安全地假设目前 99% 的 CPU 符合 IEEE 754。

【讨论】:

  • 情况不同。您列表中架构的许多实际实现几乎都支持 IEEE754,但需要注意的是没有完整的 NaN 集、强制 denorms 为零、乘法/除法结果中出现一个或两个 ULP 错误、乘法与 ULP 不同或两个取决于操作数顺序等。因此“99% 的 CPU 符合 IEEE754”需要免责声明 - 精神是真实的,就问题而言,您是正确的,但总的来说,魔鬼往往在细节中。更像是,99% 的 CPU 符合 99% 的 IEEE754。
  • @phuclv:完全支持 IEEE-754 语义的架构可能代价高昂,但并不遥远。即使在现代 CPU 上,必须处理无穷大、NaN 和非正规的所有可能极端情况的代码通常也会比可以通过稍微改变这些行为的方式进行优化的代码慢得多。
  • @moonshadow:就所提出的确切问题而言,那些归零和缺乏精度无关紧要。内存中 float/double 的格式仍然是 IEEE754 binary32 和 binary64,因此可以使用整数比较(只要它们都是正数,或者符号位处理得当)。还假设 float endian = integer endian,这个答案没有解决。
【解决方案2】:

Cell 处理器的 SPU differ in a few ways(例如缺少 INF 和 NAN),但我认为存在差异不会破坏您的假设...

【讨论】:

  • 好点。 ARM-Neon SIMD-Unit(用于较新的 iPhone 和其他移动设备)在一些方面也有所不同。不过,CPU 能够在 VPF 模式下执行符合要求的浮点计算。哦,MIPS R5900 (PlayStation 2) 也有一些问题。最值得注意的是,乘法的最后一个尾数位是未定义的。
  • 目前我的办公桌上有三个独立的嵌入式硬件,使用三个不同的 PowerPC 派生 CPU,它们在三种不同方面不兼容...
【解决方案3】:

这取决于你在“现实世界”和想象世界之间划清界限的位置。

  1. Alpha 机器仍支持 Vax G 格式(HP 表示他们将至少支持到 2013 年)。
  2. IBM z 系列大型机仍支持 IBM 十六进制 FP。他们添加了 IEEE 二进制和十进制支持,但据我所知,它们很少使用,因为十六进制 FP 快得多(IBM 已经对其进行了大约 45 年的优化......)

直到最近,Unisys 仍在销售支持 Burroughs FP 格式的 ClearPath IX 服务器和支持 Univac FP 格式的 ClearPath MCP 机器。我相信这些现在只能在仿真中运行(在 Xeons 上),但从软件的角度来看,它们可能会继续活跃使用十年或更长时间。

甚至还有一个few people 仍在使用DtCyber 在(模拟的)控制数据大型机上运行柏拉图,并具有其独特的浮点格式。 (抱歉,我第一次认真编程是在 CDC Cyber​​ 机器上进行的,所以我忍不住提出来,即使它已经有几十年没有“现实世界”了)。

【讨论】:

    【解决方案4】:

    PowerPC 处理器(大约 2006-2007 年之前的 Mac,大量当前的 IBM 服务器)使用 128 位格式,其中包含两个用于 long double 的 double,而不是 IEEE 754 扩展格式。

    但是,在 C 或 Objective-C 中,没有可移植的方式将 32 位或 64 位浮点数解释为整数(假设 float 和 uint32_t,或者 double 和 uint64_t 具有相同的位数)。当我需要做那种事情时,我必须根据编译器编写不同的代码(一个是使用联合,一个是通过将 double* 转换为 long long*)。不知道 C++ 中的 reinterpretcast 是否可以移植。

    【讨论】:

    • 1980 年代的 Macintosh“标准 Apple 数值环境”使用 32、64 和 80 位浮点类型,其中 80 位类型最快,因为可以轻松加载指数和尾数进入没有位掩码的寄存器,虽然我不知道 SANE 是否利用了这一事实,但延迟归一化可以避免有时可能是重复浮点加法中最慢的部分之一。
    【解决方案5】:

    许多现实世界的 CPU 没有任何本机浮点格式。许多用于此类 CPU 的 C 和其他语言的实现捆绑了使用 IEEE-754 单精度和双精度格式并省略了扩展精度格式的库,尽管其他格式更适合多种用途。

    【讨论】:

      猜你喜欢
      • 2014-07-17
      • 2017-03-11
      • 2023-01-03
      • 2011-04-29
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多