充分利用卡比湖上的管道

Question

（后续代码审查question here，包含此循环上下文的更多详细信息。）

---

环境：

• Windows 7 x64
• VS 2017 社区
• 在 Intel i7700k (kaby Lake) 上定位 x64 代码

我不会写很多汇编代码，而且当我写的时候，它要么足够短，要么足够简单，以至于我不必担心从中挤出最大数量的性能。我的更复杂的代码通常是用 C 编写的，我让编译器的优化器担心延迟、代码对齐等问题。

但是，在我当前的项目中，MSVC 的优化器在我的关键路径中的代码上做得非常糟糕。所以...

我还没有找到一个好的工具来对 x64 汇编代码进行静态或运行时分析，以消除停顿、改善延迟等。我所拥有的只是 VS 分析器，它告诉我（大约) 哪些指令花费的时间最多。墙上的时钟告诉我最新的变化是让事情变得更好或更糟。

作为替代方案，我一直在阅读 Agner 的文档，希望能从我的代码中获得更多性能。问题是在你完全理解之前很难理解他的任何作品。但其中的一部分是有道理的，我正在尝试应用我所学到的。

请记住，这是我最内层循环的核心，这（毫不奇怪）是 VS 分析器说我的时间花在哪里：

nottop:

vpminub ymm2, ymm2, ymm3 ; reset out of range values
vpsubb  ymm2, ymm2, ymm0 ; take a step

top:
vptest  ymm2, ymm1       ; check for out of range values
jnz nottop

; Outer loop that does some math, does a "vpsubb ymm2, ymm2, ymm0",
; and eventually jumps back to top

是的，这几乎是一个教科书式的依赖链示例：这个紧密的小循环中的每条指令都依赖于前一个操作的结果。这意味着不可能有并行性，这意味着我没有充分利用处理器。

受 Agner 的“优化汇编器”文档的启发，我提出了一种方法，（希望）允许我一次执行 2 个操作，因此我可以让一个管道更新 ymm2 和另一个更新（比如）ymm8。

虽然这是一个不平凡的改变，所以在我开始把所有东西都拆开之前，我想知道它是否可能会有所帮助。查看 Agner 为 kaby Lake（我的目标）提供的“说明表”，我发现：

        uops
        each
        port    Latency
pminub  p01     1
psubb   p015    1
ptest   p0 p5   3

鉴于此，看起来当一个管道使用 p0+p5 对 ymm2 执行 vptest 时，另一个管道可以使用 p1 在 ymm8 上执行 vpminub 和 vpsubb。是的，vptest 后面的事情仍然会堆积起来，但它应该会有所帮助。

或者会吗？

我目前正在从 8 个线程运行此代码（是的，8 个线程确实给了我比 4、5、6 或 7 更好的总吞吐量）。鉴于我的 i7700k 有 4 个超线程内核，每个内核上运行 2 个线程这一事实是否意味着我 已经 将端口最大化？端口是“每个核心”，而不是“每个逻辑 CPU”，对吗？

所以。

根据我目前对 Agner 工作的理解，似乎没有办法进一步优化当前形式的代码。如果我想要更好的性能，我需要想出一种不同的方法。

是的，我敢肯定，如果我在这里发布了我的整个 asm 例程，有人可能会建议另一种方法。但是这个问题的目的不是让别人为我写我的代码。我正在尝试看看我是否开始了解如何考虑优化 asm 代码。

这是（大致）看待事物的正确方式吗？我错过了几件吗？或者这完全是错误的？

Answer 1

TL:DR：我认为超线程应该让所有矢量 ALU 端口忙于每个核心 2 个线程。

---

vptest 不写向量寄存器，只写标志。下一次迭代不必等待它，因此它的延迟几乎是无关紧要的。

只有jnz依赖vptest，推测执行+分支预测隐藏了控制依赖的延迟。 vptest 延迟与检测到分支错误预测的速度有关，但与正确预测情况下的吞吐量无关。

---

关于超线程的好点。在单个线程中交错两个独立的 dep 链可能会有所帮助，但要正确有效地做到这一点要困难得多。

让我们看看循环中的说明。 predict-taken jnz 将始终在 p6 上运行，因此我们可以打折。 （展开实际上可能会受到伤害：predicted-not-taken jnz 也可以在 p0 或 p6 上运行）

在一个核心上，您的循环应该在每次迭代中运行 2 个周期，并受到延迟的限制。它是 5 个融合域微指令，因此需要 1.25 个周期才能发出。 （与test 不同，jnz 不能与vptest 进行宏融合）。 使用超线程，前端已经是比延迟更严重的瓶颈。每个线程可以每隔一个周期发出 4 条微指令，小于依赖链瓶颈的每隔一个周期发出 5 条微指令。

（这对于最近的英特尔来说很常见，尤其是 SKL/KBL：许多 uop 有足够的端口可供选择，因此维持每个时钟 4 uop 的吞吐量是现实的，尤其是在 SKL 改进了 uop-cache 和解码器的吞吐量以避免问题泡沫的情况下由于前端限制而不是后端填充。）

每当一个线程停止时（例如，对于一个分支错误预测），前端可以赶上另一个线程，并在乱序核心中获得大量未来的迭代，以便它每次迭代一次2个周期。 （或更少，因为执行端口吞吐量限制，见下文）。

---

执行端口吞吐量（未融合域）：

每 5 个微指令中只有 1 个在 p6（jnz）上运行。它不能成为瓶颈，因为在运行此循环时，前端发出率限制了我们每个时钟发出的分支少于一个。

每次迭代的其他 4 个向量 ALU 微指令必须在具有向量执行单元的 3 个端口上运行。 p01 和 p015 微控制器具有足够的调度灵活性，没有单个端口会成为瓶颈，所以我们可以只看总 ALU 吞吐量。对于 3 个端口，这是 4 uops / iter，对于每 1.333 个周期一个 iter 的物理核心的最大平均吞吐量。

对于单线程（无 HT），这并不是最严重的瓶颈。但是如果有两个超线程，那就是每 2.6666 个周期 1 个迭代。

超线程应该使您的执行单元饱和，并保留一些前端吞吐量。每个线程应该平均每 2.666c 一个，前端能够以每 2.5c 一个的速度发出。由于延迟仅将您限制为每 2c 一个，因此它可以在由于资源冲突导致关键路径上的任何延迟后赶上。 （vptest uop 从其他两个 uop 中的一个窃取了一个循环）。

如果您可以更改循环以减少检查频率或使用更少的矢量微指令，那可能是一个胜利。但是我在想的一切都是更多矢量微指令（例如vpand而不是vptest然后vpor在检查之前将这些结果放在一起......或者vpxor产生vptest 时的全零向量）。也许如果有向量 XNOR 或其他东西，但没有。

---

要检查实际发生的情况，您可以使用性能计数器来分析您当前的代码，并查看您为整个内核（而不仅仅是每个逻辑线程单独）获得的 uop 吞吐量。或者分析一个逻辑线程，看看它是否在 p015 的一半左右饱和。

Answer 2

部分答案：

英特尔提供了一个名为Intel Architecture Code Analyzer（描述为here）的工具，它对代码进行静态分析，显示（某种）在一段asm代码中正在使用的端口。

不幸的是：

• v2.3 不包含必要的（也是唯一的）头文件。您可以在 v2.2 中找到此文件。
• v2.2 包含标头，但省略了用于分析输出的 python 脚本 (pt.py)。此文件也未包含在 v2.3 中（尚未找到）。
• iaca 的一种输出格式是 .dot 文件，由 graphviz 读取，但英特尔文档未能描述 graphviz 中的 38 个可执行文件中的哪一个用于显示输出。

但也许最重要的是（满足我的需要）：

• v2.3（当前最新版本）支持 Skylake，但不支持 Kaby Lake。

考虑到处理器之间的实现细节如何变化，这使得所有输出都值得怀疑。 pdf 文件中的日期表明 v2.3 于 2017 年 7 月发布，这意味着我可能需要等待一段时间才能发布下一个版本。