32位数值比较是否比64位数值比较拥有更快的运行速度？

原实现的设计本质 #

• 很多人看到这段代码会误以为实现是“把完整64位浮点数截断为32位做比较”，实际上这是32位系统时代的原生设计：fdlibm最初开发时，32位CPU没有原生的64位整数读写能力，为了获取双精度浮点数的位表示，实现里会直接把IEEE754格式的double拆成高、低两个独立的32位无符号整型存储，代码里的ix变量本身存储的就是浮点数的高32位字，根本不存在“从64位值里截断取高位”的过程
• 清符号位的操作ix &= 0x7fffffff，是把高32位里最高位的符号位清零，拿到和绝对值对应的无符号字面值。由于IEEE754正浮点数的位表示顺序和数值大小顺序完全一致，对这个字面值做无符号比较，就等价于比较浮点数的绝对值大小
• 临界值0x3fe921fb就是pi/4的双精度表示的高32位部分：当浮点数的高32位小于这个值时，不管低32位是多少，它的绝对值一定小于pi/4；只有高32位等于这个临界值时，才需要额外比对低32位来确定大小。这个判断逻辑本身没有任何精度损失，完全可以正确覆盖所有需要走内核余弦计算的输入范围

64位架构下两种写法的性能对比 #

• 现代64位CPU（x86-64、ARM64平台都是）的整数运算单元原生支持64位宽度运算，32位无符号比较和64位无符号比较都是单周期可完成的操作，两者在指令层面没有任何性能差异
• 你写的全64位比较版本，是直接把双精度浮点数的64位位模式整体转成无符号整数，清掉最高位的符号位后和pi/4的完整64位位表示做比较。这个写法生成的机器码比老的拆高低位版本更简洁，不需要拆分读取内存的操作，运行速度和原实现完全持平甚至略快
• 你感知到的“全64位写法消耗更多内存”其实是认知偏差：两者的常量存储差异仅仅是32位常量占4字节、64位常量占8字节，放在现代程序的整体内存占用里可以完全忽略，不存在实质的内存开销问题
• 这里有个容易搞混的细节：你提到的常量0x3fe921fb54442d18实际对应的是pi/4的完整64位位表示，不是pi/2；pi/2的对应位表示是0x3ff921fb54442d18，实际写代码时别搞错这个临界值

当年32位比较写法的性能收益来源 #

• 这种靠高32位做快速拦截的写法，在32位CPU上的性能收益很明确：做完整的64位整数比较需要拆成“先比高32位，相等再比低32位”的两次操作，而靠高32位比较可以拦截绝大多数普通输入，把需要二次比较的场景压缩到极少数刚好落在临界值的情况，反而减少了分支判断的总开销
• 到了64位架构下，这种拆高低位的写法已经没有任何性能收益，直接做完整64位位模式比较的写法更简洁、逻辑更直白，判断结果和原实现完全等价。

内容的提问来源于stack exchange，提问作者Sayan