ハイパースレッディング＆htop / system-monitor
ハイパースレッディングを有効にしたクアッドコアXenonE5520で多数のシミュレーションを実行しています。私のソフトウェアは、8つの（仮想）コアを自動的に検出し、8つのシミュレーションを起動して並行して実行します。ただし、htopとsystem-monitorは、8つのコアのそれぞれが最大50％までロードされていることを示しています。
これは意図された動作ですか？ある意味では、物理コアごとに合計負荷が400％または100％になるので意味がありますが、それより少し多く取得するべきではありませんか？それがHTの目的ですよね？ SMTを使用して、他の方法では使用されていない実行ユニットを使用して別のスレッドを実行します。では、スループットはもっと高くなるはずですよね？
負荷は非常に一貫しており、各コアで常に50％です。シミュレーションはJavaによって実行され、単一のJVMで、GCは問題ではなく、JVMヒープ制限をはるかに下回っています。シミュレーションはメモリに縛られず、回避することがたくさんあり、スワッピングはありません。シミュレーションはディスクに大量のデータを書き込んでいますが、大きなバッファーが配置されており（スレッドごとに128MBの書き込みバッファー）、gkrellmで示されるディスクアクティビティは約90MB /秒のバーストが頻繁に発生しますが、一貫した負荷ではなく、これがボトルネックになるとは思わない。
誰かがこれに光を当てることができますか？
ただし、htopとsystem-monitorは、8つのコアのそれぞれが最大50％までロードされていることを示しています。
わかりました、それは単にあなたが同時に十分なシミュレーションを実行していないことを意味します。コアを100％使用しないシミュレーションにつながる可能性のある要素はたくさんあります。それらを修正するか、単にシミュレーションを追加します。
しかし、私はそれより少し多くを得るべきではありませんか？
すべてのコアで100％を取得できるはずです。
さて、Khaleddsの半分の知識を読んだら...ここに真実があります：
- ハイパースレッディングとは、両方のコアにすべてが備わっているわけではないことを意味します。つまり、両方のコアが特定の操作を同時に実行できない場合などです。
- しかし、彼にとって悲しいことに、これはOSには表示されません-。 CPUの「負荷」係数は、「OSスケジューラごとにコアがビジーであった時間の割合」に基づいています。したがって、CPUコアに400ミリ秒のアクティブタスクがある場合、40％ビジーです。
ハイパースレッディングリソースの枯渇（つまり、仮想コアはリソースを待機する必要があります）単純なことは、仮想コアが操作を実行するのに時間がかかることを意味しますが、これはOSスケジューラには表示されません。コアが内部で100ミリ秒待機している場合、タスクは400msではなく500msかかります。リソース不足に遭遇したときにそれを見つけるのは非常に複雑であり、OSが実行できることではありません（つまり、特別なコードを実行して実行時間を比較し、必要以上に時間がかかることを確認するものです。 =ハイパースレッディングは「悪い」。CPUがきめ細かい内部使用統計を調整する場合、最初からパフォーマンスに別れを告げることができます。つまり、データが多すぎます。
その結果、2番目のコアは100％のパフォーマンスを追加しません。したがって、ハイパースレッディングと2コアの場合、1つのコアで100ミリ秒かかる場合、50ではなく75になる可能性があります。ただし、コードに大きく依存します。
あなたの場合、私は単一のスレッドから始めて、1つのコアを100％にすることができるかどうかを理解します。そうでない場合、シミュレーションは単に何かを待っています-これはスタックオーバーフローの問題です（プログラムを変更する必要があります）。それが（IO、ディスクからの書き込み/読み取り）のようである場合、コアごとに複数のシミュレーションを実行する必要があるのは簡単かもしれません。