是否可以在 Rust 中获得 integer 的本机 CPU 大小？

Question

为了好玩，我正在 Rust 中编写一个 bignum 库。 我的目标（与大多数 bignum 库一样）是使其尽可能高效。 我希望它即使在不寻常的架构上也能高效。

在我看来，CPU 将在具有本机位数的整数上更快地执行算术运算对我来说似乎很直观（即u64用于 64 位机器， u16用于 16 位机器等）因此，因为我想创建一个对所有架构都有效的库，我需要考虑目标架构的本机 integer 大小。 执行此操作的明显方法是使用cfg 属性target_pointer_width 。 例如，要定义始终能够容纳超过最大原生 int 大小的最小类型：

#[cfg(target_pointer_width = "16")]
type LargeInt = u32;

#[cfg(target_pointer_width = "32")]
type LargeInt = u64;

#[cfg(target_pointer_width = "64")]
type LargeInt = u128;

但是，在调查此问题时，我遇到了此评论。 它给出了一个架构示例，其中本机 int 大小与指针宽度不同。 因此，我的解决方案不适用于所有架构。 另一个可能的解决方案是编写一个构建脚本，该脚本生成一个小模块，该模块根据usize LargeInt我们可以像这样获取它： std::mem::size_of::<usize>() 。）但是，这和上面有同样的问题，因为usize也是基于指针宽度的。 最后一个明显的解决方案是简单地为每个架构保留一个原生 int 大小的 map。 然而，这个解决方案是不优雅的并且不能很好地扩展，所以我想避免它。

所以，我的问题是：有没有办法找到目标的本机 int 大小，最好是在编译之前，以减少运行时开销？ 这种努力是否值得？ 也就是说，使用本机 int 大小与指针宽度之间是否可能存在显着差异？

Answer 1

通常很难（或不可能）让编译器为 BigNum 的东西发出最佳代码，这就是为什么https://gmplib.org/有其低级原始函数（ mpn_... docs ）在汇编中为各种目标架构手写针对不同的微架构进行调整，例如https://gmplib.org/repo/gmp/file/tip/mpn/x86_64/core2/mul_basecase.asm用于多肢 * 多肢数字的一般情况。 https://gmplib.org/repo/gmp/file/tip/mpn/x86_64/coreisbr/aors_n.asm用于mpn_add_n和mpn_sub_n （添加或子 = aors），针对没有部分的 SandyBridge 系列进行了调整标志停止，因此它可以与dec/jnz循环。

在使用高级语言编写代码时，了解哪种 asm 是最佳的可能会有所帮助。 虽然在实践中你甚至无法接近它，所以有时使用不同的技术是有意义的，比如在 32 位整数中只使用高达 2^30 的值（就像 CPython 在内部所做的那样，通过右移，参见本节中关于 Python 的部分）。 在 Rust 中，您确实可以访问add_overflow来获得结转，但使用它仍然很困难。

对于实际使用，为 GMP 编写 Rust 绑定可能是您最好的选择，除非它已经存在。

使用尽可能大的块是非常好的； 在所有当前 CPU 上， add reg64, reg64具有与add reg32, reg32或reg8相同的吞吐量和延迟。 因此，您每单位完成的工作量是原来的两倍。 并在 1 个延迟周期内通过 64 位结果进行传播。

（有其他存储 BigInteger 数据的方法可以使 SIMD 有用；@Mysticial 在Can long integer 例程受益于 SSE 中解释说？例如，每 32 位整数 30 个值位，允许您将规范化推迟到几个加法步骤之后。但是每次使用这些数字都必须意识到这些问题，所以它不是一个简单的替代品。）

---

在 Rust 中，您可能只想使用u64而不管目标，除非您真的关心 32 位目标上的小数（单肢）性能。 让编译器从add / adc （带进位加法）中为您构建 u64 操作。

唯一可能需要特定于 ISA 的事情是如果u128在某些目标上不可用。 您想使用 64 * 64 => 128 位全乘法作为乘法的构建块； 如果编译器可以使用u128为您做到这一点，那就太好了，特别是如果它有效地内联。

另请参阅问题下评论中的讨论。

让编译器发出有效的 BigInt 加法循环（甚至在一个展开循环的主体内）的一个绊脚石是编写一个加法，它接受一个进位输入并产生一个进位 output。 请注意，即使0xff..ff + 1回绕为零， x += 0xff..ff + carry=1也需要产生进位。 因此，在 C 或 Rust 中， x += y + carry必须检查y+carry和x+=部分中的进位。

说服像 LLVM 这样的编译器后端发出 adc 指令链真的很难（可能是不可能的）。 当您不需要从 adc 执行时，可以使用 add/adc。 或者如果编译器正在为你做u128.overflowing_add

通常编译器会将进位标志转换为寄存器中的 0 / 1 而不是使用adc 。 您可以通过将输入 u64 值组合到 u128 的u128.overflowing_add u64 希望这不会花费任何 asm 指令，因为u128已经必须存储在两个单独的 64 位寄存器中，就像两个单独u64值一样。

因此，最多组合u128可能只是对 function 的局部优化，它添加了u64元素的 arrays ，以使编译器吸得更少。

Answer 2

在我的图书馆ibig 中，我所做的是：

1. Select 基于target_arch的架构特定大小。
2. 如果我没有架构的价值，select 16、32 或 64 基于target_pointer_width 。
3. 如果target_pointer_width不是这些值之一，请使用 64。