在执行uop计数不是处理器宽度倍数的循环时性能是否会降低？

Question

在执行uop计数不是处理器宽度倍数的循环时性能是否会降低？

我想知道各种大小的循环如何在最近的x86处理器上执行，作为uop数的函数。

以下是彼得·科德斯（Peter Cordes）的一句话，他在另一个问题中提出了非多数的问题：

我还发现，如果循环不是4 uop的倍数，则循环缓冲区中的uop带宽不是每个循环的常数4。（即它是abc，abc，......;不是abca，bcab，......）。遗憾的是，Agner Fog的microarch doc对循环缓冲区的这种限制并不清楚。

问题是关于循环是否需要是N uop的倍数才能以最大uop吞吐量执行，其中N是处理器的宽度。（即最近的英特尔处理器为4）。在谈论“宽度”和计算微动时，有很多复杂因素，但我大多想忽略这些因素。特别是，假设没有微观或宏观融合。

Peter给出了以下一个循环，其中包含7个uop的循环：

一个7-uop循环将发出4 | 3 | 4 | 3 | ...的组我没有测试更大的循环（不适合循环缓冲区），看看是否有可能从下一个指令开始迭代发布在与其分支相同的组中，但我不假设。

更一般地说，声称是x在其体内具有uop 的循环的每次迭代将至少进行ceil(x / 4)迭代，而不是简单地迭代x / 4。

对于部分或全部最新的x86兼容处理器，这是真的吗？

Answer 1

这是原始答案的后续内容，根据Andreas Abel提供的测试结果分析其他五种架构的行为：Nehalem处理器珊迪大桥常春藤桥Broadwell微架构咖啡湖除了Skylake和Haswell之外，我们还快速了解这些架构的结果。它只需要一个“快速”的外观，因为除了Nehalem之外的所有架构都遵循上面讨论的现有模式之一。首先，短nop情况下运行传统解码器（对于不适合LSD的循环）和LSD。以下是针对所有7种体系结构的此方案的周期/迭代。图2.1：所有架构密集的nop性能：这个图表非常繁忙（点击查看大图）并且有点难以阅读，因为许多架构的结果彼此重叠，但我试图确保专用阅读器可以跟踪任何架构的线路。首先，我们来讨论一下这个大异常值：Nehalem。所有其他架构的斜率大致遵循4 uops / cycle周期线，但Nehalem每个周期几乎正好是3 uop，因此很快落后于所有其他架构。在最初的LSD区域之外，该线路也是完全平滑的，没有在其他架构中看到的“阶梯”外观。这与Nehalem的uop 退休限制为3 uops / cycle 完全一致。这是LSD之外的uops的瓶颈：它们每个周期都执行大约3个uop，退休时瓶颈。前端不是瓶颈，所以准确的uop计数和解码安排都无关紧要，因此没有台阶。除了Nehalem之外，其他架构，除了Broadwell之外，还可以分成几组：Haswell-like或Skylake-like。也就是说，所有Sandy Bridge，Ivy Bridge和Haswell都表现得像Haswell，因为大于15 uops的循环（在另一个答案中讨论了Haswell行为）。尽管它们是不同的微架构，但由于它们的传统解码能力相同，因此它们的行为基本相同。低于约15 uops，我们看到Haswell对于任何uop计数而言都要快一些，而不是4的倍数。由于更大的LSD或者还有其他“小循环”优化，它可能会在LSD中额外展开。对于Sandy Bridge和Ivy Bridge，这意味着小循环应该绝对定位一个uop计数，它是4的倍数。Coffee Lake的行为与Skylake 1相似。这是有道理的，因为微架构是相同的。Coffee Lake看起来比Skylake低约16 uops，但这只是Coffee Lake默认的残疾LSD的影响。Skylake已经通过启用的LSD进行了测试，之后由于安全问题，英特尔通过微码更新禁用了它。咖啡湖在这个问题出现之后就被释放了，所以LSD是开箱即用的。因此，对于此测试，Coffee Lake正在使用DSB（对于低于约18 uop的循环，仍然可以适合DSB）或传统解码器（对于其余循环），这样可以获得更好的小uop计数结果LSD强加开销的循环（有趣的是，对于较大的循环，LSD和传统解码器碰巧强加完全相同的开销，原因各不相同）。最后，我们来看看2字节的NOP，它们不够密集以防止使用DSB（因此这种情况更能反映典型代码）。图2.1：2字节nop性能：同样，结果与前面的图表一致。Nehalem仍然是每个周期3个uop的瓶颈。对于高达约60个uops的范围，除了Coffee Lake之外的所有架构都使用LSD，我们看到Sandy Bridge和Ivy Bridge在这里表现稍差，四舍五入到下一个周期，因此只实现了4的最大吞吐量uops /循环如果循环中的uops数是4的倍数。在32 uops以上，Haswell和新uarchs的“展开”功能没有任何影响，所以一切都大致相关。Sandy Bridge实际上有一些uop范围（例如，从36到44 uops），它比新架构表现更好。这似乎是因为并非LSD检测到所有循环，并且在这些范围内，循环由DSB提供。由于DSB通常更快，因此在这些情况下Sandy Bridge也是如此。英特尔说的是什么实际上，您可以在英特尔优化手册第3.4.2.5节中找到专门处理此主题的部分，正如Andreas Abel在评论中所指出的那样。在那里，英特尔说：LSD拥有构建小“无限”循环的微操作。来自LSD的微操作分配在无序引擎中。LSD中的循环以采用分支结束到循环的开头。循环结束时采用的分支始终是循环中分配的最后一个微操作。循环开始处的指令始终在下一个循环中分配。如果代码性能受前端带宽限制，则未使用的分配时隙会导致分配气泡，并可能导致性能下降。英特尔微体系结构代码名称Sandy Bridge中的分配带宽是每个周期四个微操作。当LSD中的微操作数导致未使用的分配插槽数量最少时，性能最佳。您可以使用循环展开来控制LSD中的微操作数。他们继续展示一个例子，由于LSD“四舍五入”，将循环展开一个因子2无助于性能，但是通过三个作品展开。这个例子很混乱，因为它实际上混合了两个效果，因为展开更多也减少了循环开销，因此减少了每次迭代的uop数。一个更有趣的例子就是将循环展开次数减少导致由于LSD舍入效应导致性能提高。本节似乎准确描述了Sandy Bridge和Ivy Bridge的行为。上面的结果表明，这两种体系结构都如上所述，并且对于分别具有4N + 3,4N + 2或4N + 1 uops的循环，您将丢失1,2或3个uop执行槽。但是，Haswell及其后来的新性能尚未更新。如在另一个答案中所描述的，性能已经从上述简单模型改进并且行为更复杂。1在16 uops有一个奇怪的异常值，其中Coffee Lake表现比其他所有架构都差，甚至Nehalem（回归率约为50％），但也许这个测量噪音？