floating-point - 为什么非正规浮点值的处理速度较慢？

Question

通常情况下，消耗或产生非正规数的浮点值比其他情况慢，有时慢得多。

为什么会这样？如果是因为它们陷入软件而不是直接在硬件中处理，就像在某些 CPU 上所说的那样，为什么他们必须这样做？

Answer 1

对于 IEEE-754 浮点，遇到的大多数操作数都是规范化浮点数，处理器中的内部数据路径是为规范化操作数构建的。额外的指数位可用于内部表示，以始终保持数据路径内的浮点操作数标准化。

因此，任何次正规输入都需要额外的工作来首先确定前导零的数量，然后在调整指数的同时左移有效数以进行归一化。低于正常的结果需要将有效数右移适当的数量，并且可能需要将舍入推迟到发生这种情况之后。

如果纯粹用硬件解决，这项额外的工作通常需要额外的硬件和额外的流水线阶段:一个，甚至两个额外的时钟周期，每个周期用于处理次正常输入和次正常输出。但是典型 CPU 的性能对指令的延迟很敏感，并且花费了大量精力来保持低延迟。 FADD、FMUL 或 FMA 指令的延迟通常在 3 到 6 个周期之间，具体取决于实现和频率目标。

因此，为潜在的次规范操作数添加 50% 的额外延迟是没有吸引力的，更是如此，因为次规范操作数在大多数用例中很少见。因此，使用“使常见情况快速，并使不常见情况发挥作用”的设计理念，有很大的动力将非正常操作数的处理从“快速路径”(纯硬件)插入“慢路径”(组合现有硬件加软件)。

我参与了 x86 处理器浮点单元的设计，处理 subnormals 的常用方法是在需要处理这些时调用内部微代码级异常。这种非正常处理可能需要 100 个时钟周期的数量级。其中最昂贵的部分通常不是修复代码本身的执行，而是进出微代码异常处理程序。

我知道特定的用例，例如数字信号处理中的特定滤波器，在这些用例中遇到次正规是很常见的。为了快速支持此类应用程序，许多浮点单元支持非标准的清零模式，在这种模式下，次正规编码被视为零。

请注意，存在具有显着延迟容限的面向吞吐量的处理器设计，尤其是 GPU。我对 NVIDIA GPU 很熟悉，我可以告诉他们，他们在没有额外开销的情况下处理次正规操作数，并且在过去十几年左右的时间里一直这样做。据推测，这是以额外的流水线阶段为代价的，但供应商没有记录这些处理器的许多微架构细节，因此很难确定。以下论文可能会提供一些不同的硬件设计如何处理次正规操作数的一般见解，其中一些开销很小:

E.M. Schwarz、M. Schmookler 和 S.D. Trong，“具有非规范化数字的 FPU 实现。” IEEE 计算机交易，卷。 54，第 7 期，2005 年 7 月，第 825 - 836 页