Caching 超线程和游戏（以及其他计算应用程序）？

我想知道在不同的情况下，超线程（每个物理核有多个逻辑核）的实际性能影响是什么。英特尔宣称这在执行线程等待I/O时有效，但在内存密集型应用程序中，它可能无效，因为当逻辑核之间发生切换时，处理器缓存中的局部性丢失。第二个应用程序的数据加载到缓存中，迫使第一个应用程序的内存从缓存中取出。返回到第一个应用程序时，它的引用都是缓存未命中，性能将丢失。我认识几位超级计算机经理，他们声称他们关闭了超读功能，因为这样做在他们的情况下效率更高。是否存在禁用超读更有效的“正常”用户案例？游戏可能会占用大量内存—如果没有超线程会更好吗？

首先，应该认识到，超线程是一种英特尔营销术语，用于标记事件多线程（在安腾上）和同时多线程（在x86上）的切换。SoEMT主要有利于隐藏高延迟事件，如最后一级缓存未命中，更易于实现，并且对类似VLIW的调度更友好。SoEMT也比SMT更适合小型L1（给定一个速度较快的L2），因为缓存争用更多地移动到L2或L3（线程交换机之间的数千次访问），后者可以更好地处理争用，因为它们具有更大的容量和更高的关联性。SMT可用于隐藏较小的延迟，如分支解析延迟或二级缓存命中，并提供指令级并行性，但会引入更激烈的资源争用

（禁用超线程和不使用超线程之间也有区别。禁用超线程可能会带来一点性能好处，因为即使是非活动但已启用的线程也会使用一些可共享资源，而一些分区资源可能仍会使用少量的电源，但主要好处在于：防止操作系统做出破坏性的计划决策。）

对于“普通”代码，可用的线程级并行性很可能低于可用的内核数。在这种情况下，现代操作系统通常不会使用硬件多线程，因为它认识到一个完整的内核比一个以上线程共享的内核具有更高的性能。（在特殊情况下，共享一个内核理论上可以提高性能，在这种情况下，使用L1在线程之间进行通信非常有用。此外，在活动内核上唤醒一个非活动线程要比唤醒一个内核快得多，所需能量也要少，因此在某些特殊情况下，使用多线程可能有助于提高能效。）

HPC代码往往是SMT的最坏情况。HPC代码更有可能对静态调度更友好。这意味着SMT的延迟隐藏优势趋于最小化。（类似地，HPC代码从无序执行中获益较少。）HPC代码也倾向于受内存带宽而不是内存延迟的限制。SMT可以增加每执行单元的带宽需求（通过增加缓存未命中），并通过内存控制器上的争用降低实际获得的内存带宽。（DRAM对随机访问不友好；这会导致过度刷新和行活动周期。）SMT还可能导致活动数据流的数量超过硬件对预取的支持。HPC代码也更有可能根据缓存大小（假设每个核心一个线程）被阻塞；在这种情况下，SMT将产生严重的缓存抖动

禁用超线程也可能对组调度操作更友好，这在HPC中很常见。如果只有部分内核使用多线程，则这些内核可能具有更高的每个内核的性能，但每个线程的性能会更低；这会迫使其他内核空闲地等待较慢的线程完成。（HPC系统可能有专用的操作系统内核和备用内核，以避免类似的问题，操作系统活动会减慢一个内核/线程的速度并迫使数百个其他内核等待，或者出现故障的内核可能会导致，例如，一个16线程组计划的程序先运行15个线程，然后运行一个线程，执行时间加倍。）

（理论上，SMT可以在HPC中使用，以减少某些优化循环中的寄存器压力，因为双线程内核中的FMADD等操作的有效延迟可以被视为大约减半。因为编译器通常使用固定延迟进行调度[SMT被视为透明功能]，即使在可能有益的情况下，利用此功能通常也不实用。）

与无序执行类似，SMT对不规则代码最为有利（OoO在单个代码流中展望指令级和内存级并行性；SMT在线程之间“横向”展望此类并行性）如果分支预测失误和缓存未命中很常见，SMT可以使用现有的线程级并行性来隐藏此类延迟（分支预测失误的成本主要在于解决延迟）

SMT的好处因工作负载和特定硬件而异。像最初的Intel Atom这样的深度流水线有序微体系结构比较浅的流水线OoO微体系结构更能从SMT中获益（延迟，特别是分支解析延迟，通常更高，管道更长，OoO提供了一些SMT线程级并行所使用的并行性）

启用的超线程还可能具有增加应用程序使用的线程数的缺点，在应用程序中，随着线程数的增加，性能扩展足够次线性，使用超线程的每个线程的较低性能将导致性能的净损失。例如，如果提供了每个核心两个线程的超线程p增长了30%