我正在启用超线程的四核 Xenon E5520 上运行大量模拟。我的软件自动检测 8 个（虚拟）内核并启动 8 个模拟以并行运行。然而 htop 和系统监视器只显示 8 个内核中的每一个都加载到 ~50%。
这是有意的行为吗？在某种程度上，这是有道理的，因为每个物理核心的总负载为 400% 或 100%，但我不应该得到更多吗？我的意思是这就是 HT 的目的，对吗？使用 SMT 使用其他未使用的执行单元来运行另一个线程。所以吞吐量应该更高吧？
我应该提到负载非常一致，每个核心始终为 50%。模拟由 Java 运行，在单个 JVM 中，GC 不是问题，我远低于 JVM 堆限制。模拟不受内存限制，有很多东西可以使用，没有交换。模拟正在向磁盘写入大量数据，但有大缓冲区（每个线程 128MB 写入缓冲区）并且 gkrellm 显示的磁盘活动频繁爆发 ~90MB/s 但它不是一致的负载，我可以相信这可能是一个瓶颈。
任何人都可以对此有所了解吗？
好的，这只是意味着您没有同时运行足够的模拟。有许多因素会导致模拟不使用 100% 的核心。要么修复这些问题，要么简单地添加更多模拟。
您应该能够在每个核心上获得 100%。
现在，如果你读了 Khaledds 的半知半解......这是事实：
超线程资源匮乏（即虚拟核心必须等待资源）将简单意味着虚拟核心需要更长的时间来执行操作 - 但这对操作系统调度程序来说是不可见的。如果核心在内部等待 100 毫秒，则任务将花费 500 毫秒而不是 400 毫秒。试图找出何时遇到资源匮乏是相当复杂的，而且这不是操作系统可以做的事情（即你可以在其中运行特殊代码并比较运行时间以查看一个时间比它应该花费的时间更长） = 超线程“坏”。如果 CPU 会调出细粒度的内部使用统计数据，你几乎可以告别任何开始的性能 - 那是太多的数据。
结果是第二个核心根本不会增加 100% 的性能——所以如果某件事在一个核心上需要 100 毫秒，使用超线程和 2 个核心可能需要 75，而不是 50。不过，这在很大程度上取决于代码。
在你的情况下，我会从一个线程开始，然后弄清楚你是否可以让一个核心达到 100%。如果没有，那么模拟只是在等待某些东西——如果有的话，这就是一个 stackoverflow 问题（必须更改程序）。如果它是（IO，从磁盘写入/读取），那么每个核心运行超过 1 个模拟可能很简单。