如何解释矩阵乘法GFLOP / s中的这种差异？

Question

我正在尝试从这个维基here进行一些矩阵乘法优化。在测量天真，三倍循环的Matmul的GFLOP / s时，我希望看到特定大小后的GFLOP / s下降，根据Wiki，这表示数据不再适合缓存：

我在2台不同的PC上运行了基准测试：

• 第三代Intel i5（3210M） ：（ L1 =每个内核32KB，L2 =每个内核256KB，L3 = 3MB共享）。
  我得到了预期的图形，从〜2GFLOP / s急剧下降到0.5。

• 第六代Intel i7（6500U） ：（ L1 =每核32KB，L2 =每核256KB，L3 = 4MB共享）
  在此上，即使尝试使用更大的尺寸，我仍会看到GFLOP / s逐渐降低。查看Ubuntu系统监视器，其中一个CPU核心始终处于100％使用状态。

我正在尝试了解以下内容：

1. 我如何解释矩阵大小导致的GFLOP / s的变化？如果预期的下降与不再适合缓存的数据相对应，为什么即使i7的尺寸更大，我也看不到这种下降？
2. 对于较小的尺寸，第三代i5的性能如何更快？
3. 如何解释CPU占用率？如果将更多的时间用于从缓存/ RAM提取数据，我会看到CPU使用率的降低吗？

修改：
我从GsonBuilder builder = new GsonBuilder() builder.registerTypeAdapter(MyResult.class, new MyResultDeserializer()); 切换到double，并尝试了float和-O3，这是图。我无法检查odler i5的频率，但是Skylake i7在整个过程的大部分时间内几乎都立即达到了涡轮增压频率。
来自here的代码在i7上使用GCC 7.4.0，在i5上使用clang（Apple LLVM 7）。

Answer 1

关于问题2： 虽然两个CPU的基本频率和涡轮频率相同，但Ivy Bridge的TDP为35W，而Skylake的TDP为15W。即使采用了更新的过程，Ivy Bridge仍可能能够使用其涡轮程序进行较大的计算。 （彼得·科德斯（Peter Cordes）已经提到检查实际涡轮增压器。）

关于问题3： CPU利用率不取决于CPU在做什么，等待RAM仍然算作利用率。您可以查询一些性能计数器，这些计数器会告诉您常春藤桥是否较慢，因为它会更频繁地停滞于内存。

Answer 2

通过有效的缓存阻止，密集的内存应该成为ALU的瓶颈，而不是内存带宽。 O（N ^ 3）在O（N ^ 2）内存上工作。

但是您正在测量天真 matmul。这意味着，如果要逐步减少一个输入的列，那总是很可怕的。这是缓存阻塞/循环平铺的经典问题。

您的Skylake的L3缓存和DRAM带宽明显更好，并且L2缓存的关联性较低（4路而不是8路）。不过，我希望当您的工作集适合L2时，性能会比不适合时更好。

与IvyBridge相比，SKL可能还具有更好的硬件预取功能，并且绝对有较大的无序窗口大小。

IvyBridge（包括您的3210M）是引入下一页硬件预取的一代，但是我认为具有该名称的功能只是TLB预取，而不是数据。这可能不是一个因素，尤其是如果透明的大页面可以避免任何TLB遗漏的话。

但是，如果不是这样，则TLB丢失可能是导致IvB中断的真正原因。 使用性能计数器进行检查。（例如perf stat）

---

您的CPU频率是否立即达到了最大涡轮增压并在两个CPU处都保持在那里？ @idspispopd的答案也对总功率/散热预算提出了一些意见，但是请检查您的两个系统是否为此保持相同的CPU频率。否则，请记录下它们是什么。

您在启用优化的情况下进行编译，对吗？如果没有，那可能足以掩盖内存瓶颈的开销。您是否在两个系统上使用相同的编译器/版本/选项？您使用过-march=native吗？