CPUzとOCCTを使い分けてテストをしています。CPUzを複数のスレッドでCPUにストレスを与えるように設定した場合、70cを超えることはないことに気がつきました。一方、CPUに負荷をかけるためにOCCTを実行していると、すぐに75cを超えてしまい、時には85cでテストを停止してしまうこともあります
ここで何が起こっているのでしょうか？私はいつも理解していたのですが、ビデオカードにはたくさんのコアがあって個別に負荷をかける必要がありますが、CPUは単純なものです。基本的なforループはCPUに100%の負荷をかけることができます。複数のスレッドで実行される多くのforループは、すべてのコアに負荷をかけることができます。OCCTはどうしてこんなにもCPUを発熱させているのか。CPUzができないことを何でさせているのか？
いくつかの背景情報。CPUはIntel Core i7-4790k。ターボブーストは有効になっていますが、どちらかのプロセスが実行されているときに5％でハングアウトするだけだと思います
36 Andrey 2020-06-29
CPUの使用率とは、CPUがどれだけのリソースを持っているかを示す指標ですが、処理できる命令には様々な種類があり、それぞれ処理能力やメモリの必要量が異なります
メモリを多用するタスクは、メモリからデータを取得している間にCPUをストールさせ、CPUを「使用中」にしたままで有効な命令スループットを低下させる可能性があります
また、CPUの飽和度が違う部分も多々あります
Wikichipsより サンディ橋のアーチ
初期命令デコーダのフロントエンドがあることがわかりますが、複雑で多様な命令ストリームの場合、残りのパイプラインをフルに保つのに苦労するかもしれません
整数の加算しかできない場合は、CPUには3つのINT ALUユニットがあるので、コア実行ユニットのうち3つを使用することができます。浮動小数点の乗算しかできない場合は、1つのFPUのMUL(multiply)ユニットのみを使用することができます
また、CPUはパイプラインとしても動作しており、ある実行ユニットで1つのユニットが使用されている間に、次のサイクルで動作をスケジュールすることができます。つまり、使用中ではないユニットは同じEUでも、異なる命令タイプでスケジュールすることができるので、多様な命令ストリームがリソースをより有効に活用できるということです。また、異なる命令は、異なる実行時間を持ち、実行するための関連回路のセットが大きくなったり小さくなったりします。単純な加算は1～2クロックサイクルで実行できますが、浮動小数点命令の場合は実行時間が長くなり、関連する回路の量も多くなります。時間がかかるということは、より多くの電力を消費することを意味し、回路の面積が大きくなる可能性があります。あるいは、命令が長くなるということは、フロントエンドのスケジューリング回路が一時停止して実行可能なユニットを待つ間に消費電力が少なくなることを意味しているかもしれません
その結果、CPUをフルに活用するためには多様な命令ストリームが必要であり、あるCPUを動かしても、実行ユニットの配置や数、能力の違いにより、別のCPUを完全に動かせるとは限りません
実行ユニットは、最新のパワーゲーティング方式で「ローパワー」になり、結果としてデバイスの熱出力に寄与しないか、または寄与度が大幅に低くなります
キャッシュは消費電力にも貢献します。キャッシュを使用することは、命令とデータをフェッチし、その結果、キャッシュには大きすぎるメモリ内のデータセットを持つルーチンよりも高速に実行できることを意味します
その結果、プログラムや命令ストリームによってピーク時の電力使用量が異なるため、温度が異なる場合があります
プロセッサ世代間でのアーキテクチャの違いや、同世代でもキャッシュサイズ、プロセッサオプション、異なる命令の利用可能性が影響している可能性があります
46 Mokubai 2020-06-29
マルチスレッドのクランチテストを実行しても、モノスレッドのテストのようにCPUが熱くならない理由を知りたいのはわかります
簡単に説明すると、ターボブーストはCPUが複数のコアで等しく頑張っているときに無効化されるので、ターボブーストが原因だということです。1つのコアを多用しているときにのみ有効になります（しかも1つのコアのみ）
ターボブーストがアクティブな場合、それはより多くのパワーをブーストされたコアにシャントし、他のコアへのパワーを減少させ、その結果、それらを遅くします
ブーストされたコアは高速で動作し、ブーストされていないコアよりも発熱します。これをセンサーが捉え、1つのコアの温度をCPU全体の温度として報告します
12 harrymc 2020-06-29
CPUの「負荷」（または使用量）は、CPU時間のうち、「有用な」アクティビティと「アイドル」時間のどちらに何％が費やされているかを示すアクティビティモニタです。オペレーティングシステムは、何が「有用な」活動で何が「アイドル」時間かを決定します
CPU負荷が0%の場合、OSはその時間間隔の間、ユーザプロセスをスケジューリングしていません。 CPU負荷が50%の場合、OSはユーザープロセスのために約半分の時間間隔をスケジュールしており、残りの半分の時間間隔はアイドルループに費やされています。ユーザープロセスが1つだけであっても、そのプロセスはCPU負荷が高くないため、例えばI/O処理が完了するのを待っている間にスケジュールを変更しなければならないため、CPU負荷の100%を消費することができない場合があります。 CPU負荷が100%の場合、OSは全ての時間間隔をユーザプロセスにスケジューリングしています
CPUは実際には（電源が入っているときは）常にビジー状態、つまり常に命令を実行していることに注意してください。実行する準備ができている(ユーザ)プロセスがない場合、OS スケジューラはアイドルループを実行しなければなりません
CPUの温度は、CPU回路で消費される電力の影響を受けます。より多くのトランジスタスイッチが発生すると、より多くの電力が必要とされ、消費され、CPU温度が上昇します。 この消費電力はCPUの「負荷」では示されませんが、これは時間ベースのアクティビティモニタに過ぎません。 プロセスは、メモリ内のデータ（ロード命令やストア命令など）をコピーしたり移動したりするだけで、CPUを（時間的に）「ビジー」に保つことができます（アイドル時よりも大きな追加電力負荷ではありません）。 一方、別の計算集約的なプロセスは、ALU（演算/論理ユニット）やFPU（浮動小数点ユニット）などのCPU内の他の多くの回路を利用した計算（乗算や除算命令など）を実行することができます
つまり、プロセスが実行する命令の組み合わせ（すなわち命令の種類）によって、消費電力とそれに続く温度レベルが決まります。 OSはこの消費電力を測定することができず、CPU負荷と温度センサーを使用した時間ベースのアクティビティ測定のみを報告します
9 sawdust 2020-06-29
追加の注意点として、発熱のほとんどは CPU 内部のビットが 0 と 1 の間で反転するときに発生し、「処理」されるときに発生するのではありません。ALU パイプラインでゼロのストリームをプッシュすると、ランダムなビットのストリームをプッシュするよりもはるかに少ない熱量で発生します。これは、パイプラインが停止しているときに起こると予想されることでもあります：パイプラインには一定の値が供給されますが（有用な結果は得られません）、CPUの負荷推定の目的では100%ビジー状態です
これは必ずしもあなたのケースで起こっていることではありません（@harrymcはそれを釘付けにしたと思います）。私が言いたいのは、CPU負荷と消費電力は直接関係のない別の物理量であるということです
4 Dmitry Grigoryev 2020-07-01
例を挙げてみましょう。2つのループを取ります
for (i = 0; i < 1000000000; ++i) {
x += a [i];
}
and
for (i = 0; i < 1000000000; ++i) {
x += a [i];
y += a [i];
z += a [i];
}
最初のループでは、プロセッサは次の加算を開始する前に、前の加算が終了するのを待たなければなりません。加算のレイテンシが3サイクルの場合、プロセッサは3サイクルごとに1つの加算を実行します。CPUの負荷は100%ですが、CPUは実際にはそれほど多くの仕事をしていません
2回目のループでは、3サイクルに1回の繰り返しもありますが、加算は独立しているので、プロセッサは3サイクルに3回の加算を行い、3倍の仕事をすることになります。CPU負荷は100%のままですが、3倍の作業を行うと、より多くの熱が発生します
そのため、各サイクルで利用可能なコンピューティングリソースをより多く使用するコードでは、より多くの熱を得ることができます
1 gnasher729 2020-07-01
