超线程是否存在AVX问题?

时间:2015-05-19 15:32:56

标签: multithreading avx hyperthreading

在玩超频和运行刻录测试时,我注意到,启用超线程时,AVX优化版LINPACK测量的多线程浮点吞吐量低于禁用超线程时的多线程浮点吞吐量。这是在Ivy Bridge i7(3770k)上。我还注意到,尽管我在较低的核心电压下运行CPU,但是使用超线程禁用LINPACK导致更高的核心温度。所有这些让我相信,如果没有超线程,管道利用率实际上更高。

我很好奇:这只是LINPACK算法固有的东西导致管道停滞或SMT效率低下的分配,或者英特尔的SMT实现合法地在两个线程调度管道时都遇到了麻烦发布宽SIMD指令?如果是这样,那么Haswell已经解决了这个问题,还是将来会在未来的英特尔架构中解决?这是AVX512容易出现的问题吗?

最后,在使用AVX进行英特尔系统编程时,是否有任何好的步骤可以避免使用SMT进行低效的流水线分配?

1 个答案:

答案 0 :(得分:6)

超线程共享两个硬件线程之间的无序执行资源,而不是将它们全部交给一个线程。通常情况下,如果一个线程已经可以保持管道满,那么在最坏的情况下看不到加速。无论哪种方式,执行单元都应该咀嚼需要运行的4个uop / clock指令。

如果每个线程都在自己的内存块上运行,那么CPU核心就会尝试同时处理更多的实时数据。 L1 / L2缓存的竞争共享意味着最终可能比没有HT更糟糕。

此外,某些工作负载具有并行化的开销。只有令人尴尬的并行问题(比如做很多独立的matmuls,而不是并行化一个大问题),协调线程的开销可以忽略不计。

正如Agner Fog在他的Optimizing Assembly手册中提到的,如果任何竞争共享或分区的CPU资源是瓶颈,超线程将无济于事,并且可能会受到伤害。当代码花费大量时间在分支错误预测或缓存未命中时,这是非常好的,因为另一个线程可以使饥饿的管道保持空闲状态。

Matrix数学具有可预测的足够的访问模式,缓存未命中和错误预测很少见。 (特别是在为缓存大小小心阻止的代码中。)

如何避免HT没有帮助:使代码变慢,因此单个线程无法有效地执行它以保持管道满。 >&LT ;.但严重的是,如果有一个缓存未命中或分支错误预测的算法与蛮力方法相比表现相同,那么使用它可能会有所帮助。例如考虑到单个线程上的分支错误预测的开销,早期的测试可能几乎是一次洗,但是当你的代码在同一个核心的两个HW线程上运行时,可能要快得多,所以蛮力的方式是在缺点