2

我正在调整我的 GEMM 代码并与 Eigen 和 MKL 进行比较。我有一个具有四个物理核心的系统。到目前为止，我一直使用 OpenMP 的默认线程数（我的系统上为 8 个）。我认为这至少与四个线程一样好。但是，我今天发现，如果我在一个大型密集矩阵 (1000x1000) 上运行 Eigen 和我自己的 GEMM 代码，我使用四个线程而不是八个线程可以获得更好的性能。效率从 45% 跃升至 65%。我认为这也可以在这个情节中看到 https://plafrim.bordeaux.inria.fr/doku.php?id=people:guenneba

差异是相当大的。但是，性能不太稳定。使用 Eigen 和我自己的 GEMM 代码，每次迭代的性能都会有所提高。我很惊讶超线程使性能变得如此糟糕。我想这不是一个问题。这是一个意想不到的观察结果，我希望能得到反馈。

我看到这里也建议不使用超线程。
如何加快 Eigen 库的矩阵乘积？

我确实有一个关于测量最大性能的问题。我现在要做的是运行 CPUz 并在运行 GEMM 代码时查看频率，然后在我的代码中使用该数字（在我使用的一个超频系统上为 4.3 GHz）。我可以相信所有线程的这个数字吗？我如何知道每个线程的频率以确定最大值？如何正确计算涡轮增压？

4

3 回答 3

4

超线程的目的是提高表现出高延迟的代码的 CPU 使用率。超线程通过同时处理两个线程来掩盖这种延迟，从而具有更多的指令级并行性。

但是，编写良好的矩阵乘积内核表现出出色的指令级并行性，因此可以利用近 100% 的 CPU 资源。因此，没有第二个“超”线程的空间，其管理的开销只会降低整体性能。

于 2013-04-19T15:26:48.493 回答
2

除非我错过了什么，否则总是有可能的，你的 CPU 有一个时钟由它的所有组件共享，所以如果你在 4.3GHz（或其他）测量它的速率，那么这就是所有组件的速率，找出一个有意义的速度。如果不是这样，想象一下混乱，一些核心以一种速度运行，另一些核心以另一种速度运行；共享组件（例如内存访问）将变得无法管理。

至于超线程实际上会恶化矩阵乘法的性能，我并不感到惊讶。毕竟，超线程是穷人的并行技术，复制指令流水线而不是功能单元。一旦你的代码在n*10^6通过 FPU 推动你的连续内存位置时尖叫，响应管道停顿的上下文切换不会有太大帮助。在最好的情况下，另一个管道会在另一个上下文切换抢走你有用的时钟周期之前尖叫一段时间，最坏的情况是，内存层次结构中所有仔细排列的数据在每次切换时都会被严重破坏。

超线程不是为了并行数值计算速度而设计的，而是为了提高更一般的工作负载的性能；我们在高性能计算中使用通用 CPU 不是因为我们想要超线程，而是因为所有专业的并行数字 CPU 都已经走上正轨。

于 2013-04-19T15:14:52.507 回答
1

作为多线程并发服务的提供者，我探索了超线程如何在各种条件下影响性能。我发现，对于将其自身的高利用率线程限制为不超过实际可用物理处理器的软件，HT 的存在与否几乎没有什么区别。尝试使用比繁重计算工作更多线程的软件可能没有意识到它正在这样做，仅依赖于总处理器数量（在 HT 下翻倍），并且可以预见地运行得更慢。启用 HT 可能提供的最大好处可能是，您可以最大限度地使用所有物理处理器，而不会让系统的其余部分陷入瘫痪。如果没有 HT，软件通常不得不腾出一个 CPU 来保持主机系统正常运行。

于 2013-09-07T19:17:06.507 回答