超线程对 gettimeofday 和其他时间测量的影响答案

【问题标题】：Hyperthreading effects on gettimeofday and other time measurements超线程对 gettimeofday 和其他时间测量的影响
【发布时间】：2014-12-12 17:05:51
【问题描述】：

当我在 C 语言中使用超线程和 BLAS 矩阵运算对 CPU 进行基准测试时，我观察到使用超线程时函数的运行时间几乎翻了一番。由于乱序执行或其他优化，我期望的是某种速度的提高。

我使用 gettimeofday 来估计运行时间。为了评估观察结果，我想知道您是否对 gettimeofday 在超线程环境（Debian Linux 32 位）中的稳定性或我的期望（他们可能是错误的）有想法？

更新：我忘了提到我正在运行基准测试应用程序两次，每次都将亲和性设置为一个超线程核心。例如 gemm 并行运行两次。

【问题讨论】：

如果您的代码和数据在很大程度上适合缓存（尤其是 L1，但也可能在 L2 中），而 BLAS 之类的事情是设计/优化的，那么该代码的执行将缺乏大部分超线程在其中调度来自另一个线程的指令的管道停顿和冒泡，这几乎击败了超线程。

标签： c hyperthreading gettimeofday

【解决方案1】：

我怀疑您对 gettimeofday() 的使用是否解释了这种差异，除非您测量的时间间隔可能非常小。

更重要的是，我不希望启用超线程来提高单线程 BLAS 计算的性能。单个线程（一次）只使用一个处理器，因此超线程提供的额外逻辑处理器无济于事。

经过良好调整的 BLAS 可以充分利用 CPU 的数据缓存来减少内存访问时间。但是，如果从缓存中清除所需的数据，这并没有多大帮助，因为当同一物理 CPU 的另一个逻辑处理器执行不同的进程时，很可能会发生这种情况。即使在负载较轻的系统上，也可能有足够的工作要做，以使操作系统始终在每个可用（逻辑）处理器上安排一个进程。

【讨论】：

抱歉，我忘了说我正在并行运行 blas 函数。
你没有抓住重点。 BLAS 本身是单线程的，因此单个计算不会受益于可用的额外内核（无论是物理的还是逻辑的）。另一方面，每个人的缓存使用都会受到在同一物理 CPU 上运行的另一个 BLAS 计算的不利影响，就像在该物理 CPU 上运行的随机无关计算一样。