See Agner Fog 的微架构指南 https://agner.org/optimize/对于这样的管道详细信息。https://www.realworldtech.com/haswell-cpu/ https://www.realworldtech.com/haswell-cpu/还通过框图对 Haswell 进行了深入研究。 （以及 David Kanter 关于其他 uarches 的一些文章的链接，例如 SnB 和 Core2，以及 AMD Bulldozer 和 K8。）还有其他链接https://stackoverflow.com/tags/x86/info https://stackoverflow.com/tags/x86/info
是的，现代 x86 核心是超标量乱序执行。自 PPro 以来，基本原理没有改变：将 x86 机器代码解码为可由 ROB + RS 调度的微操作 (uops)。
（术语：Intel 使用“issue”表示“复制到无序后端”，“dispatch”表示“从调度程序发送到执行单元”，分配资源并更新 RAT。在计算机体系结构领域的其他许多领域，人们使用相反的术语。）
自 Core 2 以来，Intel 在发布/重命名/分配阶段是 4 uops 宽的超标量，这是最窄的瓶颈。（在此之前，从 PPro 到 Pentium-M，都是 3 宽。）Core 2 在实践中很少能维持这种状态，因为有太多其他瓶颈。 Skylake 在高吞吐量代码中通常可以非常接近。
为了让每个融合域 uop 进行更多工作，ALU uop 与其内存源负载进行了微融合。以及宏观融合，例如cmp/test + jcc 因此比较和分支指令一起解码为一个 uop。 （请参阅 Agner Fog 的微架构指南）。这包括您的 Kaby 或 Coffee Lake CPU。最大未融合域持续吞吐量为每个时钟 7 uop，Skylake 实践中可实现 https://www.agner.org/optimize/blog/read.php?i=857。在突发情况下，调度程序可以将微指令分派到每个端口。
Ice Lake (Sunny Cove uarch) 将问题阶段扩大到 5。
AMD Zen 的宽度为 6 uops，但只有 5指示 wide，因此当运行至少一些 2 uop 指令时，它只能达到 6 uop/时钟。例如256 位 AVX SIMD 指令将其解码为 2x 128 位一半（或者对于跨车道洗牌来说更糟）。
Skylake 将传统解码器扩展到 5 uops/时钟，并将 uop 缓存获取从 SnB 中的 4 uops 通过 Broadwell 提高到 6 uops/时钟。这会更多地隐藏前端气泡，并在高吞吐量代码中更多地让问题/重命名阶段每时钟输入 4 个微指令。 （阶段之间有缓冲区/队列，例如为问题/重命名阶段提供数据的 64 uop IDQ。）
这包括您的 Kaby 或 Coffee Lake CPU：在微架构上，KBL 中的 IA 核心与 SKL 相同，而 Coffee Lake 是一个非常小的调整（修复了由于部分寄存器合并 uop 而 SKL 必须在微代码更新中禁用的循环缓冲区）勘误表，又名 CPU 错误）。 KBL 和 CFL 的 GPU 比 SKL 更好，但 x86 内核基本相同。
是的，对于大多数代码来说，超过 3 或 4 宽的收益递减，但 SMT 可以让宽核同时在两个（或 4 或 8）个执行线程中找到 ILP。这使得更宽的核心不会被浪费，但核心的成本与宽度的关系大于线性比例，因此只有在以下情况下才这样做有时单个线程可以使用该宽度的大部分。否则你只会构建更多更小的核心。 （至少如果你有一个可扩展的互连用于更多核心......）我的回答为什么不制造一个大的CPU核心呢？ https://electronics.stackexchange.com/questions/443186/why-not-make-one-big-cpu-core/443342#443342关于电子产品。SE 提供了有关实际工作负载中可用的权衡和有限 ILP 的更多详细信息。
