performance - 在大多数现代 64 位处理器上, `mulq` 的速度是否取决于操作数?

标签 performance assembly x86-64 cpu intel

在大多数现代 64 位处理器(例如 Intel Core 2 Duo 或 Intel i7 系列)上,x86_64 命令的速度 mulq它的变体取决于操作数?例如,将乘以 11 * 1311111111 * 13131313 快?还是总要经历最坏的情况?

最佳答案

TL;DR:否。无论操作数的数值如何,恒定长度的整数数学运算(除除法外,这是非线性的)消耗恒定数量的周期。
mulq需要两个 QWORD 参数。

这些值以 little-endian 二进制格式(由 x86 架构使用)表示,如下所示:

1011000000000000000000000000000000000000000000000000000000000000 =       13
1000110001111010000100110000000000000000000000000000000000000000 = 13131313

处理器将这两个视为相同的“大小”,因为它们都是 64 位值。

因此,无论操作数的实际数值如何,循环计数都应始终相同。

更多信息:

有先导零预期和先导零检测的概念[ 1 ][ 2 ] (LZA/LZD) 可用于加速浮点运算。

然而,据我所知,没有主流处理器采用这两种方法进行整数运算。这很可能是由于大多数整数算术(在这种情况下为乘法)的简单性所致。 LZA/LZD 的开销可能根本不值得,因为简单的整数数学电路无论如何都可以在更短的时间内完成完整的乘法运算。

关于performance - 在大多数现代 64 位处理器上, `mulq` 的速度是否取决于操作数?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10903836/

相关文章:

c++ - 帮助理解生成的部分汇编代码

assembly - 为什么某些 SSE "mov"指令指定它们移动浮点值?

c++ - 如何为arduino编译V-USB?

x86-64/Windows 下正确的上下文切换

从 nasm x86-64 调用 c 函数

javascript - 如何知道哪个 JavaScript 函数执行时间最长?

性能问题 : Async gRPC with Gunicorn + Tornado

android - 对于 android 开发,我可以在 ImageView 上使用 JPG 图像而不是 PNG 图像吗?

c - 为什么clang用-O0产生效率低的asm(对于这个简单的 float 和)?

ruby - 为什么 .index 比 .all 快?