我正在对软件进行基准测试，该软件在英特尔 2670QM 上的执行速度比使用我的所有 4 个"逻辑"线程的串行版本快 8 倍。我希望社区对我对基准测试结果的看法提供一些反馈。
当我在 4 个内核上使用 4 个线程时，我的速度提高了 4 倍，整个算法是并行执行的。这对我来说似乎是合乎逻辑的，因为"Amdhals定律"预测了这一点。Windows任务管理器告诉我我正在使用50%的CPU。
但是，如果我在所有 8 个线程上执行相同的软件，我会再次获得 4 倍的速度，而不是 8 倍的速度。
如果我理解正确：我的 CPU 有 4 个内核，频率分别为 2.2GHZ，但当应用于 1.1 个"逻辑"线程时，频率分为 8GHZ，其余组件(如缓存(也是如此？如果这是真的，那么为什么任务管理器声称我的 CPU 只有 50% 被使用？
#define NumberOfFiles 8
...
char startLetter ='a';
#pragma omp parallel for shared(startLetter)
for(int f=0; f<NumberOfFiles; f++){
...
}
我没有包括使用磁盘 I/O 的时间。我只对 STL 调用所需的时间(STL 排序(感兴趣，而不是磁盘 I/O。
i7-2670QM 处理器有 4 个内核。但它可以并行运行 8 个线程。这意味着它只有 4 个处理单元(内核(，但在硬件上支持并行运行 8 个线程。这意味着最多有四个作业在内核上运行，如果其中一个作业由于例如内存访问而停止，另一个线程可以非常快速地开始在空闲核心上执行，而几乎没有损失。阅读有关超线程的更多信息。实际上，在少数情况下，超线程会带来很大的性能提升。更现代的处理器比旧的处理器更好地处理超线程。
您的基准测试显示它是 CPU 密集型的，即管道中几乎没有停滞，这会使超线程具有优势。50% CPU 是正确的，4 个内核正常工作，而额外的 4 个内核没有做任何事情。在BIOS中打开超线程，您将看到100%的CPU。
这是超线程的快速摘要
线程切换很慢，必须停止执行，将一堆值复制到内存中，将一堆值从内存中复制到 CPU，然后使用新线程重新开始工作。
这就是您的 4 个虚拟内核的用武之地。你有 4 个内核，就是这样，但超线程允许 CPU 做的是在单个内核上有 2 个线程。
一次只能执行 1 个线程，但是当 1 个线程需要停止执行内存访问、磁盘访问或任何其他需要一些时间的事情时，它可以切换另一个线程并运行它一段时间。在旧处理器上，他们基本上在这段时间里睡了一会儿。
因此，您的四核有 4 个内核，每个内核一次可以做 1 件事，但一旦他们需要等待计算机的另一部分，就可以有第二个待机作业。
如果你的任务有大量的内存使用和大量的CPU使用率，你应该看到总执行时间略有减少，但如果你几乎完全受CPU限制，你最好只坚持4个线程。
这里要了解的重要信息是物理线程和逻辑线程之间的区别。
如果您的 CPU 上有 4 个物理内核，这意味着您有物理资源并行执行 4 个不同的执行线程。因此，如果您的线程没有数据争用，您通常可以测量与单线程速度相比的 x4 性能提升。
我还假设操作系统(或您:)(正确设置了线程相关性，因此每个线程在每个物理内核上运行。
在 CPU 上启用 HT(超线程(时，不会修改内核频率。
:)发生的情况是硬件管道的一部分(核心内部和周围(非核心、缓存等((是重复的，但其中一部分仍在逻辑线程之间共享。这就是您不衡量 x8 性能提升的原因。根据我启用所有逻辑内核的经验，您可以获得每个物理内核 x1.5 - x1.7 的性能改进，具体取决于您正在执行的代码、缓存使用情况(请记住，L1 缓存在两个逻辑内核/1 个物理内核之间共享，例如(、线程相关性等。希望这有帮助。
HT在大多数BIOS中被称为SMT(同步多线程(或HTT(超线程技术(。HT 的效率取决于所谓的计算与提取比率，即代码在从慢速主内存或 I/O 内存获取或存储到慢速主内存或 I/O 内存之前执行了多少次核心内(或寄存器/缓存(操作。对于高缓存效率和 CPU 密集型代码，HT 几乎没有明显的性能提升。对于更多的内存绑定代码，由于所谓的"延迟隐藏"，HT 确实有利于执行。这就是为什么大多数非 x86 服务器 CPU 每个内核提供 4 个(例如 IBM POWER7(到 8 个(例如 UltraSPARC T4(硬件线程的原因。这些 CPU 通常用于数据库和事务处理系统，其中同时处理许多并发内存绑定请求。
顺便说一下，Amdhal定律指出，并行加速比的上限是代码的串行部分的上限。通常，如果线程之间存在(可能隐藏在运行时中(通信或其他同步，则串行分数会随着处理元素的数量而增加，尽管有时缓存效应会导致超线性加速，有时缓存垃圾会大大降低性能。
一些实际数字：
我的 i7 上的 CPU 密集型任务(将 1-1000000000 的数字添加到 int var 中，16 次(，平均超过 8 次测试：
摘要，线程/即时报价：
1/26414
4/8923
8/6659
12/6592
16/6719
64/6811
128/6778
请注意，在下面报告中的"使用 X 线程"行中，X 比可用于执行任务的线程数大 1 - 一个线程提交任务并在倒计时闩锁 evnet 上等待完成 - 它不处理任何 CPU 密集型任务，也不使用 CPU。
8 tests,
16 tasks,
counting to 1000000000,
using 2 threads:
Ticks: 26286
Ticks: 26380
Ticks: 26317
Ticks: 26474
Ticks: 26442
Ticks: 26426
Ticks: 26474
Ticks: 26520
Average: 26414 ms
8 tests,
16 tasks,
counting to 1000000000,
using 5 threads:
Ticks: 8799
Ticks: 9157
Ticks: 8829
Ticks: 9002
Ticks: 9173
Ticks: 8720
Ticks: 8830
Ticks: 8876
Average: 8923 ms
8 tests,
16 tasks,
counting to 1000000000,
using 9 threads:
Ticks: 6615
Ticks: 6583
Ticks: 6630
Ticks: 6599
Ticks: 6521
Ticks: 6895
Ticks: 6848
Ticks: 6583
Average: 6659 ms
8 tests,
16 tasks,
counting to 1000000000,
using 13 threads:
Ticks: 6661
Ticks: 6599
Ticks: 6552
Ticks: 6630
Ticks: 6583
Ticks: 6583
Ticks: 6568
Ticks: 6567
Average: 6592 ms
8 tests,
16 tasks,
counting to 1000000000,
using 17 threads:
Ticks: 6739
Ticks: 6864
Ticks: 6599
Ticks: 6693
Ticks: 6676
Ticks: 6864
Ticks: 6646
Ticks: 6677
Average: 6719 ms
8 tests,
16 tasks,
counting to 1000000000,
using 65 threads:
Ticks: 7223
Ticks: 6552
Ticks: 6879
Ticks: 6677
Ticks: 6833
Ticks: 6786
Ticks: 6739
Ticks: 6802
Average: 6811 ms
8 tests,
16 tasks,
counting to 1000000000,
using 129 threads:
Ticks: 6771
Ticks: 6677
Ticks: 6755
Ticks: 6692
Ticks: 6864
Ticks: 6817
Ticks: 6849
Ticks: 6801
Average: 6778 ms