assembly - 为了流水线，实际的 Intel x86 处理器有多少开销？

Question

关闭。这个问题需要 details or clarity .它目前不接受答案。

---

想要改进这个问题吗？ 通过 editing this post 添加详细信息并澄清问题.

关闭 6 年前。

Improve this question

在我的研究生计算机架构上，教授谈到了 MIPS 中的流水线，但也说由于 x86 指令集的某些情况(我不太记得)，x86 处理器需要有一个额外的逻辑来预-处理汇编指令和管道。

我不是在寻找直接的数字答案，而不是寻找有关该主题的文档或提示:正在做什么来翻译 x86 指令以允许流水线化，此逻辑如何工作等等。

非常感谢。

Answer 1

http://realworldtech.com/ 上的许多论坛帖子就晶体管数量/性能/功率而言，“x86 税”与 x86 CPU 的成本相比，与 MIPS 等易于解码的 ISA 相比，已经争论了多少。

10% 是一个被广泛猜测的数字。其中一些成本是固定的，并且不会随着您使 CPU 更强大而扩展。例如可能需要 3 个额外的流水线阶段才能将 x86 指令解码为复杂性与分离 MIPS 指令相似的微指令流。具有内存目标的 ADD 可能会解码为加载、添加和存储。 (管道某些部分的微融合使其比这更复杂。)

并行解码可变长度 x86 指令非常耗电(当前设计中每个时钟最多 4 个)。 x86 不仅仅是可变长度，确定长度(即下一条指令的开始)需要查看很多位，因为有可选的前缀和各种其他复杂性。 Agner Fog's blog post about the "instruction set war" Intel 和 AMD 之间讨论了 x86 操作码编码空间困惑状态的一些成本。 (另请参阅他的 microarch pdf，了解 AMD 和 Intel 的现代 x86 设计中的管道，旨在发现实际代码中的瓶颈/了解性能计数器，但如果您只是好奇 CPU 的工作原理，这也很有趣)。

解码 x86 指令的成本如此之高，以至于 Intel's Sandybridge microarchitecture family uses a small/fast decoded-uop cache以及传统的 L1 I-cache。即使是大型循环通常也适合 uop 缓存，与从传统解码器运行相比，可以节省电力并提高前端吞吐量。大多数其他 ISA 无法从解码指令缓存中获得几乎相同的好处，因此它们不使用它们。 (Intel 之前在 Pentium 4 中尝试过解码的 uop 跟踪缓存(没有 L1 I-cache，并且解码器更弱)，但是 SnB 的 uop 缓存不是跟踪缓存，旧的解码器仍然是足够快。)

OTOH，x86 的一些遗留包袱(如部分 FLAGS 更新)对管道的其余部分和无序核心产生了成本。现代 x86 CPU 确实必须分别重命名 FLAGS 的不同部分，以避免在 DEC/JNZ 之类的东西中出现错误的依赖关系。 (其中 DEC doesn't modify CF )。英特尔尝试不这样做(在 Pentium4 又名 netburst 微架构系列中)。他们认为他们可以强制每个人使用避免 INC/DEC 的编译器重新编译他们的代码，并使用 add eax, 1 (它确实修改了所有标志)。 ( This optimization advice stuck around for ages in their official optimization manual, long after P4 was obsolete, and many people think it's still relevant .)

---

有些人认为 x86 强大的内存排序语义应该被视为“x86 税”的一部分，它减少了流水线 CPU 可以利用的并行性，但其他人(例如 Linus Torvalds)认为让硬件为您完成这意味着您不需要在多线程代码中到处都是屏障指令。并且让屏障指令“便宜”(不是完全刷新存储缓冲区或其他)需要硬件足够详细地跟踪内存顺序，以便它们可能只是隐含屏障。