我试图找出英特尔HT在Linux X86_64中的性能影响。
是否有众所周知的工具或现成的代码来做这个测试?
如果没有，我的测试计划如下，
场景1:
线程1:高优先级，在CoreN Thread0中运行，睡眠1秒。
线程2:中优先级，在CoreN Thread0中运行，增加整数计数器
线程3和4是与1和2相同的线程，但将在CoreN Thread1中运行。
1秒后，线程1和3将分别打印线程2和4增加的计数器。
场景2:
然后将线程3和4移到不同的核心，运行1秒再次检查计数器
期望在场景2中整数相加的性能优于场景1。
检查Intel HT对性能的影响，我的测试计划是否合理?
如果您的工作负载本质上是固定数量的线程，多于物理内核的数量，那么您的测试方式可能是有意义的。因此，您需要比较两个线程争夺同一核心(上下文切换)和两个线程共享同一物理核心的逻辑核心。
这是不正常的，大多数多线程工作负载可以将自己划分为可变数量的线程，因此您可以选择与您的核心匹配的线程数量。
通常您会使用N个线程执行x265之类的操作，其中N是您拥有的物理内核的数量。(像ffmpeg -preset slow -c:v libx265 -x265-params pools=4对于一个4核的NUMA池)。理想情况下，在引导时禁用HT，或者将每个HT对中的一个内核脱机，这样Linux就不会将两个线程调度到同一个物理内核上。
然后使用2N个线程，让所有的逻辑内核保持忙碌，所以看看扩展到更多的线程是否有助于或损害工作负载的吞吐量。(隐藏摊位vs.通过竞争缓存空间/内存带宽创建更多摊位)
在我的测试中，没有打扰离线核心，只是在i7-6700k Skylake上使用双通道DDR4-2666, 1080p x265编码，预设较慢的速度下pool =8 vs. pool =8，速度提高了约20%。
但是8个线程使用更多的内存带宽(根据intel_gpu_top -l显示集成的内存控制器读/写带宽)，并且使交互使用明显更加缓慢。(要么是由于L3缓存的额外竞争，要么是由于没有空闲的逻辑核来调度任务，或者两者兼而有之。)
或者如果你想微基准运行两个简单的循环对对方很长一段时间(而不是像x265或BLAS SGEMM的真实程序的指令组合，或make -j8编译，或其他东西)，那么是的，你会写简单的循环，并在perf stat下运行它们，看看现实是否匹配你可能从前端vs后端(特别是不同的特定端口)vs.延迟瓶颈的代码预测。
参见https://stackoverflow.com/tags/x86/info，特别是https://agner.org/optimize/- Agner的microarch指南有关于如何在超线程之间共享CPU核心的不同部分的相当详细的信息。(例如，ROB和存储缓冲区是静态分区的，缓存和执行单元是竞争性共享的，除非有一个线程停滞，否则前端是交替的。)