我在启用了Hyper-Threading的四核氙E5520上运行了大量的仿真。 我的软件会自动检测8个（虚拟）核心，并启动8个模拟并行运行。 但是htop和系统监视器只显示8个内核中的每一个加载到〜50％。
这是预期的行为？ 在某种程度上，这是有道理的，因为每个物理核心的总负载将是400％或100％，但我不应该得到多一点？ 我的意思是HT的目的是对的？ 使用SMT来使用其他未使用的执行单元来运行另一个线程。 所以吞吐量应该更高的权利？
我应该提到，负载是非常一致的，每个核心，一直是50％。 模拟是由Java运行的，在单个JVM中，GC不是问题，我低于JVM堆的限制。 模拟不受记忆的束缚，有很多东西可以四处走动，不需要交换。 模拟正在向磁盘写入大量数据，但是存在大量缓冲区（每个线程有128MB写入缓冲区），而gkrellm所显示的磁盘活动频繁发生〜90MB / s的突发，但这不是一个一致的负载，我可以不相信这可能是一个瓶颈。
有没有人可以对此有所了解？
但是htop和系统监视器只显示8个内核中的每一个加载到〜50％。
好吧，这只是意味着你没有在同一时间运行足够的模拟。 有很多元素可以导致100％的模拟不使用内核。 要么你修复这些，要么你只是添加更多的模拟。
但是我不应该多一点呢？
你应该能够在每个核心100％。
现在，如果你阅读Khaledds一半的知识…这是事实：
超线程资源匮乏（即虚拟内核必须等待资源）简单地说，虚拟内核需要更长时间才能执行操作 – 但这对操作系统调度程序是不可见的。如果内核在内部等待100ms，则任务将花费500ms而不是400ms。 当你遇到资源匮乏的时候，试图找出它是相当复杂的，而且它不是操作系统能够做的事情（比如，你运行特殊的代码并比较运行时间，看看是否需要更长的时间=超线程“不好”，如果CPU能剔除细粒度的内部使用统计数据，那么你可以说开始任何性能的告别 – 这是太多的数据。
结果是第二个核心不会增加100％的性能 – 所以如果一个核心需要100ms的时间，超线程和2个核心可能需要75个而不是50个。然而，这取决于代码。
在你的情况下，我将开始一个单一的线程，并找出是否可以得到一个100％的核心。 如果不是，那么模拟只是在等待一些东西 – 这是一个stackoverflow的问题，如果有的话（程序必须改变）。 如果它是这样的话（IO，从光盘写入/读取），那么对每个内核运行多于一次的模拟可能是简单的。