CPU bound vs Cache bound - 可以在没有缓存/内存访问的情况下执行指令吗？内存访问可以和指令执行一样快吗？答案

【问题标题】：CPU bound vs Cache bound - Can instructions be executed without cache/memory access? Can memory access be as fast as instruction execution?CPU bound vs Cache bound - 可以在没有缓存/内存访问的情况下执行指令吗？内存访问可以和指令执行一样快吗？
【发布时间】：2017-04-26 07:11:26
【问题描述】：

我正在查找 CPU 绑定程序和 IO 绑定程序之间的区别。那时我遇到了answers，它解释说还有其他变体，例如内存绑定、缓存绑定等。

我了解内存绑定（主内存中 2 个大型矩阵的乘法）和 IO 绑定 (grep) 以及 CPU 绑定/缓存绑定之间的差异。

但是，CPU Bound 程序和 IO Bound 程序之间的区别似乎并不那么清楚。这是我收集的：

缓存限制 - 缓存访问速度是决定程序执行速度的重要因素。例如，如果程序中访问最多的部分是循环内的一小段代码，小到足以包含在缓存中，那么该程序可能是缓存绑定的。

CPU 限制 - CPU 执行指令的速度是决定程序执行速度的重要因素。

但是进程怎么会受 CPU 限制呢？我的意思是，每次执行前都需要（从缓存/主内存）获取指令，因此，无论 CPU 有多快，它都必须等待缓存完成数据传输，因此至少会被缓存绑定或内存绑定，因为内存访问比指令执行慢。

那么 CPU 绑定和缓存绑定一样吗？

【问题讨论】：

指令需要在执行前获取（从缓存/主内存）。几乎所有 CPU 都使用拆分 L1 缓存，因此指令获取不会与数据加载/存储竞争（以及其他原因）。当代码在 L1 缓存中很热时，缓存本身并不是瓶颈。获取/解码瓶颈称为“前端”瓶颈。
此外，指令每次运行时都需要从 L1 I-cache 中获取甚至不是真的：Intel SnB 系列 CPU 具有解码的微指令缓存和循环缓冲区，因此它们无需重新解码指令即可运行中到小循环。
我没有听说过缓存绑定这个词，但我认为这意味着工作集适合 L2 或 L3 缓存，但不适合 L1 缓存。因此，对于比 L1D 更大、更慢的缓存，带宽和/或延迟的代码瓶颈。可能会特别提到代码缓存瓶颈，因为这相对不寻常。
如果你想具体一点，有不同类型的 CPU 绑定（front-end, latency, or throughput of a specific execution port，还有分支错误预测）。这些区别可以决定超线程（或任何其他类型的 SMT）是否有用。具有大量分支错误预测或延迟瓶颈的代码可能会通过 HT 很好地扩展，因为每个线程都没有充分利用内核的执行吞吐量。

标签： performance operating-system cpu cpu-architecture cpu-cache

【解决方案1】：

CPU 架构很像管道，只是没有异味。当其中一个管道堵塞时，其他一些会溢出，而另一些会保持空置——这两种情况都是不好的利用，但你需要找到堵塞来释放所有东西。同样，对于 CPU，您有多个系统需要协同工作以使程序进展。这些机器中的每一个都有其可以工作的带宽上限，当达到上限时，它将成为一个限制，使其他系统未得到充分利用甚至停滞不前。

例如，主内存取决于通道数量和 DRAM 的类型（当然还有频率），但假设它在客户端 CPU 中的峰值通常为 25G/s。这意味着任何尝试使用超过此速率的数据的工作负载都将被内存 BW（即内存限制）阻塞，而其余系统将未得到充分利用。

缓存带宽取决于缓存级别（和处理器微架构，当然还有缓存域的频率），但您可以在优化指南中找到它的峰值。

根据 2.1.3 here，例如 Intel Skylake 从 L1 提供 2 个 32B 负载 + 每个周期 1 个存储（尽管他们引用的实际利用率略低，可能是由于冲突或回写干扰），L2实际上每个周期大约 1/2 行，而 L3 略小于 1/3。这意味着，如果您的数据集包含在这些级别之一中，您可以在被该缓存限制之前达到峰值带宽。

另一方面，假设您没有达到峰值缓存带宽，而是以较低的速率消耗 L1 中的数据，但每个数据元素都需要许多复杂的数学运算。在这种情况下，您可能会受到执行带宽的限制——如果这些操作仅限于部分执行端口（如某些深奥操作的情况），则更是如此。

有一些有用的工具可以确定你的界限 - 例如查找 TopDown analysis

【讨论】：

我认为英特尔优化手册（~83B/c IIRC）引用的 HSW/BDW/SKL 持续 L1 吞吐量低于峰值（96B/周期）的实际原因是不完善的 uop 调度。每次将存储地址 uop 调度到 p23 而不是 p7 时，它都会阻止该端口执行加载。
不，我这是他们为 STA 添加了一个特殊端口，请参见此处的端口图 - wccftech.com/…，甚至表示其目的是减少负载争用
对，那是端口 7。它只能处理简单的寻址模式（非索引 IIRC，但不要引用我的话）。存储地址 uop 仍然可以分配给端口 2 和 3。即使对于可能在端口 7 上运行的简单寻址模式，这在实践中也会发生。uop -> 端口分配发生在发布时，基于提供启发式图片的计数器每个端口的争用。显然，逻辑并没有特例 port7 并强制 STA uops 在可能的情况下使用它。
另请参阅stackoverflow.com/questions/40681331/… 了解 uop 调度详细信息，尽管它不关注端口 7。无论如何，拥有端口 7 确实显着减少了端口 2 和 3 的争用，这就是为什么即使是持续吞吐量高于 64B/c。