コードで100%CPUを使用しないのはなぜですか?[閉まっている]


42

Windows XP以降で実行されるC#.NET 4プログラムについて具体的に説明していますが、一般的な回答も受け入れられます。

すでに最適化された効率的なプログラムを想定します。ここでの問題は、ハードウェアのCPU使用率が高いことの影響と、実装を効率化するかどうかではなく、使用率の高いプログラムを制限して摩耗を減らすかどうかにかかっています。

今日の同僚は、「最新のCPUは安価であり、100%のCPUで急速に劣化する」ため、データロードプロセスで100%のCPU使用率を目指してはならないと提案しました。

これは本当ですか?もしそうなら、なぜですか?以前は、集中的な操作や長時間の操作には100%のCPU使用率が望ましいという印象を受けていましたが、どちらの方法でも対象に関する立派なソースを見つけることができませんでした。


6
アプリケーションがボックス上で実行されている唯一のものであると仮定すると、厳密に言うと、100%のCPU使用率は実際には悪くはありませんが、むしろ、もっと良い方法があり得ることを示している可能性があります。私はデスクトップアプリをあまり使用していませんでしたが、たとえば、Webアプリの場合、CPU負荷を最大化するアプリケーションを見たことはなく、これらのサイクルを使用するコードが本当に最適でした。常に何か問題があります。ただし、これはWeb上ではI / Oに縛られることが多いため、CPUの問題は不適切と思われます。あなたのアプリは違うと思います。
ブランドン14年

7
また、異なるオペレーティングシステムは、このケースを異なる方法で処理します。たとえば、私のWindowsボックスは、CPUが100%使用されている場合、ひどく実行されます。一方、LinuxサーバーがCPU使用率100%で数日間稼働しているのを見たことがありますが、問題ありませんでした。(ただし、数日後に修正プログラムをリリースしました。)
ブランドン14年

17
無駄にしないで、できるだけ早く仕事をしたい。CPUの100%を使用して有用な計算を行う場合、それは適切です。無駄なループでCPUを100%使用すると、無駄になります。
nwp 14年

10
あなたはそれのすべてを支払った。それをすべて使用します。
ブライアンフーパー14年

4
この質問は、プログラミングではなく電子機器に関するものであるため、トピックから外れているようです。

回答:


59

冷却が不十分な場合、CPUが過熱する可能性があります。しかし、すべて(少なくとも最新のすべてのPC CPU)には、クロック速度を調整したり、最終手段としてシャットダウンしたりするさまざまな熱保護メカニズムが備わっています。

したがって、はい、ほこりだらけのラップトップでは、100%のCPU負荷が一時的な問題を引き起こす可能性がありますが、何も破損または「劣化」しません(それが何を意味するにせよ)。

CPUバウンドの問題の場合、100%のCPU負荷が適切な方法です。

アプリケーション(UI)の応答性に関しては、CPU使用率とは別の概念です。1%CPUを使用する応答しないアプリケーション、または100%CPUを使用する応答アプリケーションを使用することは完全に可能です。UIの応答性は、UIスレッドで実行される作業量、およびUIスレッドと他のスレッドの優先順位に要約されます。


3
OSはコアのクールダウンスライスを強制することもあります
ラチェットフリーク14年

8
本当の答えは、ほとんどのプロセスはCPUバウンドではなく、I / Oバウンドであるということだと思います。それが一般的に、少なくとも「一般/汎用」計算では、100%CPU使用が異常な世界に住んでいる理由です。
ウインドファインダー14年

4
@windfinder「計算」の場合、100%を達成することは非常に標準的ですが、「計算」が数学で何かをしなければならない限り:) MySQLクエリの処理は計算ではありません;)
yo '

@tohecz-私が使った意味では、計算は単にCPU時間を意味します。ここでは、用語について口論しているだけです。CPUが行うことはすべて、計算(「計算」)だけです。データサイエンティストとして、ほとんどの数学もI / Oバウンド(最も単純な数学以外)であるとも言います。数学の世界での多くの時間は、CPU使用率を可能な限り高く保つために(もちろんキャッシュの非効率性を最小限に抑えながら)データをプロセッサに効率的に圧縮/ストリーミングする方法を見つけることです。
ウインドファインダー14年

4
Anecdote re "dusty laptop":修士論文の実験では、当時4歳のラップトップをランナーとして使用しました。約3か月間、24時間年中無休の100%CPU使用率。その後、ラップトップはさらに4年間サーバーの役割に追いやられた後、最終的にゴーストを放棄しました(おそらくグラフィックスの破損が原因です)。
ミコワク14年

15

Windowsプログラム(winforms / WPF)は常に応答性を維持する必要があります。100%のCPUリソースを使用するプロセスの単純な実装では、プログラムやシステムでさえも動作が遅くハングしているように見えるのは非常に簡単です。

適切な実装(たとえば、優先度の低い別のスレッドを使用する)であれば、問題になりません。

CPUがすぐに壊れる心配はありません。


3
もちろん、長期的な計算を行うプログラムは、おそらくwinforms / wpfアプリケーションではなく、UIのない​​バッチジョブである必要があります。これにより、レスポンシブUIスレッドを気にする必要がなくなり、タスクスケジューラなどを介して起動できるようになります。UIが必要な場合は、完全に別のプロセスでランチャーアプリケーションを使用することをお勧めします(非常に簡単に応答性を維持できます。バッチジョブからのステータスメッセージの待機をブロックするのに十分です)。
ジャン・ヒューデック

15

通常、100%CPU 使用するプログラムは、実際に有用な作業を行っており、より重要なものから時間を奪ってはいませんが、問題はありません。特定のハードウェアプラットフォームが、たとえば、過熱を避けるために50%にスロットルバックする前に1秒間100%CPUを連続的にしか使用できない場合、一般に、実行する有用な作業があるアプリケーションの方が適切です。可能な限り高速に実行し、CPUまたはOSが必要な調整を処理できるようにします。これは、アプリケーションが実行すべき速度を推測するためです。アプリケーションまたはスレッドに低優先度の作業があり、それが有用であるが常に重要ではない場合、OSが低優先度タスクのCPU使用率を50%に制限すると、CPUが必要な場合に役立ちますすぐに「スプリント」できる状態になりますが、アプリケーションは、低いスレッドの優先度を要求する以上のことを心配するべきではありません。

100%CPUを使用するのが悪い最大の状況は、次のいずれかの場合です。

  • アプリケーションは、永続的なポーリングによって急いでするつもりされていない[とタスクが行われているかどうかをチェックする無駄な努力はそう費やされる可能性がCPUリソースを占有している場合、実際に遅れることがありますいくつかのイベントのためビジー待ちでやってタスクを]。

  • アプリケーションが頻繁にディスプレイを再描画しています。「過度に頻繁に」の定義は、ある程度は表示デバイスの性質と表示されるコンテンツに依存します。ディスプレイハードウェアが120fpsを表示できる場合、モーションブラーを追加せずに120fpsでアニメーションを表示できても、追加せずに低いフレームレートできれいに表示できない場合があります。モーションブラーを使用してフレームをレンダリングする場合、なしでレンダリングするよりもはるかに時間がかかる場合、それをサポートするハードウェアで120fpsでレンダリングすることは、実際にはモーションブラーを使用して低速のフレームレートでレンダリングするよりもコストがかかりません。[単純な状況:スポークが29個あり、1秒間に1回転するホイール。120fpsでは、ホイールは適切な速度と方向で回転しているように見えます。60fpsで、

前者は明らかに悪いと認識されます。2つ目はもう少し微妙です。モバイルプラットフォームをターゲットにしている場合、バッテリーの寿命は気にならないが最高品質のアニメーションが必要なユーザーもいれば、低品質を受け入れるユーザーもいるため、ユーザーが目的のアニメーションフレームレートを選択できるようにすることが望ましい場合がありますより良いバッテリー寿命と引き換えにアニメーション。アプリケーションがトレードオフの位置を推測しようとするのではなく、ユーザーがそれをカスタマイズできるようにすると役立つ場合があります。


10

「最新のCPUは安価で、100%CPUで急速に劣化します」。

この質問の「劣化」部分に実際に対処した人はいないと思います。ダイの温度がメーカーの制限を超えると、ICが劣化します。ICは通常、最大125° Cで動作するように設計されていますが、10 ° Cを増やすごとに寿命が50%短くなります

プロセッサーには、常に熱制御が備わっていませんでした。その後、いくつかのAMD Duronsで問題が発生しました(ヒートシンクなしで実行すると問題が発生する可能性があります)。これで、すべてのPCプロセッサにCPUクロックにフィードバックする温度センサーが組み込まれ、損傷を防ぐためにクロックが遅くなります。そのため、プログラムが使用可能なCPUの100%を使用しているのに、冷却が不十分なためにCPUが定格速度の75%でしか動作していないことがわかります。

ユーザープログラム内では、CPU消費を管理しようとする正しい場所ではありません。一般に、プログラムは、できるだけ速く処理することと、入力またはディスクアクセスを待機、中断することを交互に行う必要があります。可能であれば、ビジーウェイトおよびスピンロックを回避する必要がありますが、システムの残りの部分に配慮してください。

WindowsとLinuxの両方に、パフォーマンスと温度管理を行うCPU「govenor」システムがあります。これはOSレベルで実行されるため、システムのCPU総消費量を考慮することができます。ハードウェアを管理し、ユーザープログラムがハードウェアを誤用しないようにするのは、オペレーティングシステムの責任です。ファンを清潔に保ち、動作を維持することはハードウェアの所有者の責任であり、製造業者は最初に適切なヒートシンクとファンを取り付けることです。

デバイスの冷却が不十分な場合がいくつかありますが、多くのリターンがあるため、メーカーは冷却しないようになっています。


爆発するAMD Duronのビデオは、おそらく偽物です。温度調節に関する声明は引き続き有効です。
サム14年

1
うーん、グーグルで偽物だというかなりの主張を見ることができるので、私はそれを削除しました。
pjc50 14年

3
SSEエンジンをプッシュするコードを記述し、OSでCPUスロットリングを意図的に無効にすることにより、最新のIntel Core CPUを過熱させることができます。製造元(Intel自体も)は、CPUが常にクロックサイクルごとに主張された4フロップを計算することを強制するのが通常ではない(可能性がある)という仮定に基づいて熱要件を設計しているようです。誰かが実際にそれを行うコードを書くことに成功すると、彼のCPUは過熱し始めます。参照:stackoverflow.com/questions/8389648/...
slebetman

^「ヒートシンクなしで実行すると1つを破壊できると言われています」- ヒートシンクなしで以前のK7を破壊できることが「個人的に確認」されました。ほぼ20年前のようなものですか?
user2864740

3

悪魔の擁護者を演じるには:ある意味では、100%の使用率に達することができないプログラムは、より悪い摩耗を引き起こす可能性があります:キーストロークを待って中断しない限り、ほとんどの場合、ディスクI / Oを待って中断する可能性があります。また、ディスクは(通常は)大きな機械装置であり、電力消費はもちろんのこと、移動する際に機械的摩耗や衝撃/ジャイロ効果のリスクがあります。


この場合、それは大規模な(メモリ内の)データセットに対する単純な複雑なプロセスであり、数分かかります。しかし、それは他の読者にとって間違いなく良い点です。
ニックウデル14年

3

「..現代のCPUは安価で、100%のCPUで急速に劣化します」。

「CPUの低下」を心配する必要はまったくありません。最近のCPUは、以前ほど品質が低下していません。

CPUを製造するのは非常に高価です(数年ごとにさらに高価になっています)。新しいfabを構築するための数十億は珍しくありません(リンクを参照)。

http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant

CPUの生産コストはせいぜいnoに依存します。生産されたユニットの。これは経済のよく知られた事実です。結局、(比較的)「安く」売れるのはそのためです。(ここにリンクは必要ないと思います)

最近のCPUが「以前の時代」よりも品質が高い傾向があると考える理由をいくつか挙げることができます。

ただし、最も重要なのは、テストの利点です。現代の電子機器は「テスト用に設計されています」。ソフトウェアであろうとハードウェアであろうと、テストを他のほぼすべてのものに対して評価するという幅広い洞察はそれほど古くはありません。CPUの場合、さまざまな価格と周波数タイプを形成するためのテストも行われます。たとえば、最高のCPUが最高の周波数で販売されています。それにもかかわらず、安価なプロセッサーは販売されているよりも高い頻度で動作することが非常に多いです。メーカーが「高レベル」のプロセッサーをより高い価格で販売したいという理由でのみ機能しません。

(一方で、70年代のプロセッサーの数千個のトランジスターよりも、現在通常の15億個以上のトランジスターを搭載したプロセッサーの方が、より多くのエラーが発生する可能性があります。少なくともマイクロコードに多くの既知のエラーがある傾向がありますが、これはここでは対象外です。

プログラムのCPUの劣化を心配しないさらに多くの理由があります。

  • 最初の理由は、最新のCPUが熱くなっている場合、周波数またはスロットルを下げることです。

    CPUを1年中24時間年中無休で使用すると、通常は1時間おきに1週間しか使用しないCPUよりも早く消滅することは明らかです。しかし、それは車についても同様です。そのような場合にのみ、CPU使用率と潜在的なスリープについて考えます。

  • 2番目の理由は、OSからCPUを100%使用するプログラムを作成するのが非常に難しいことです(Windowsなど)。また、最新のCPU(通常)には少なくとも2〜4コアがあります。したがって、シングルコアCPUの100%を使用する傾向がある従来のアルゴリズムは、デュアルコアCPUで50%のみになりました(単純化されていますが、実際のシナリオで見られます)。

  • さらに、オペレーティングシステムはプログラムではなくCPUを制御するため、同じまたはより高い優先度(デフォルト)を持つ他のアプリケーションがある場合、プログラムはできるだけ多くのCPUを取得しますが、他のアプリケーションは取得しません。飢えます。(もちろん、これは単純化された理論にすぎず、もちろんWindows、Linuxなどのマルチタスクは完全ではありませんが、全体的にはそれが本当だと考えます)。

「以前は、集中的な操作や長時間の操作には100%のCPU使用率が望ましいという印象を受けていました。」

はい、これにとどまります。しかし、たとえば、別のプロセスを待機してループする、つまり何もしない場合、そのループでThread.Sleep()をミリ秒にして、他の人に余分な時間を与えてもそれほど悪くはありません。優れたマルチタスクOSには必要ありませんが、Windows 2000などではこれに関するいくつかの問題を解決しました(もちろん、計算でSleep()を使用することを意味するわけではありません。


3
今日、この答えは真実ですが、将来への懸念があります。以前は「ソリッドステート」は最高の信頼性を意味していましたが、現在ではブロックごとに1000消去サイクルしか評価されていないMLCフラッシュがあります。100%で常に動作する必要のあるCPUで、ダイサイズの縮小により同様の現象が生じるまでの時間
マイケル14年

2
@ Michael、CPUは変化しませんが、揮発性メモリに書き込みますが、それでもあなたが言おうとしていることは理解しています。
ピーター14年

3

このような劣化は理論的に可能であり、「エレクトロマイグレーション」と呼ばれます。エレクトロマイグレーションは温度に依存し、温度が上がると加速します。最近のCPUにとって実際的な問題であるかどうかは、議論の余地があります。最新のVLSI設計手法はエレクトロマイグレーションを補償し、チップは他の理由で故障する可能性が高くなります。

とはいえ、エレクトロマイグレーションは通常の負荷と温度も発生しますが、十分に設計されたチップが故障するずっと前に陳腐化するか、最初に別のメカニズムを介して故障するほど遅いです。

エレクトロマイグレーションの速度はチップ温度に依存し、寿命は10°Cごとに倍増します(非常に大まかに)。これは、実際には、「HTOL」(高温動作寿命)と呼ばれるテストの基礎であり、これは、たとえば125°Cでチップが死ぬのにかかる時間を測定します。125°Cで動作するチップは、55°Cで動作するチップの約100倍の速度で故障するため、55°Cで少なくとも10年持続するように設計されている場合、125°Cで1か月以内に故障する可能性があります。85°Cのようなもっと合理的なもので動作する場合、そのようなチップは設計されたよりも少なくとも5-10倍早く故障します。

もちろん、CPUは通常、より高い温度を念頭に置いて設計されているため、通常は85°Cで24時間年中無休で100%の負荷で動作します。したがって、CPUの「消耗」については心配せず、ソフトウェアエンジニアリングの観点から100%の負荷が適切かどうかだけを心配することをお勧めします。


その単語を見つけると、SEネットワーク全体で読みやすい多くの結果が得られます。その多くはElectronics.SEおよびSuperUserにあります。

1

クライアントでコードを実行している場合、CPU使用率が100%の場合、その時点のクライアントコンピューターは、優先度の高いタスク以外には使用できません。通常、ほとんどのアプリケーションはデフォルトの優先度で実行されるため、これらのコンピューターを使用しているユーザーはコンピューターがフリーズすることに気付き、コンピューターで他のことを行うことができなくなります。短いバーストについて話している場合でも、何かに取り組んでいるユーザーはそれを認識します。

他の人が言ったように、あなたはセットアップについてかなり秘密でしたので、私は確かに言うことができません。ただし、クライアントがデスクトップコンピューターの場合は、CPU使用率が100%にならないようにしてください。CPUの性能低下のためではなく、作業中にユーザーを混乱させるのは良い方法ではありません。


6
Windowsはこのように機能します。Linuxおよびその他の多くのシステムでは、何か(ユーザー入力)を待機するスレッドは、割り当てられた時間を使用して自動的にスレッドよりも優先されるため、優先順位を設定しなくても対話型プログラムは応答し続けます。
Jan Hudec 14年

2
@JanHudec Windowsは実際にそれを行います。superuser.com/questions/194223/...
NtscCobalt

@NtscCobalt:はい。明らかにそうではないのはWindows CEです。また、プロセスがディスク上で重い場合は常にWindowsに深刻な問題がありますが、それは明らかに異なるものです(Windowsの一般的なディスク処理はかなり貧弱です)。
ジャン・ヒューデック

1

したがって、状況は次のとおりです。すべてのCPUを100%使用して5時間実行するコードがあります。可能な限り最適化され、マシンの所有者は5時間使用できないマシンで問題ありません。すべてのCPUの83.33%を使用して6時間でコードを実行する方が良いと主張しています。これは、コンピューターの消耗が少ないためです。

使用しているコンピューターによって異なります。コンピューターメーカーが、24時間年中無休の科学的な環境で使用されていた安価な家庭用コンピューターの保証期間内に保証修理を拒否したことは知っています。顧客がより高価なサーバーまたは「ビジネス」コンピューターを購入することを明確に望んでいました。それらが成功したかどうかはわかりません。

私が所有しているすべてのMacには、そのライフランコードのある時点で、一度に数日間CPU使用率100%のコードがあります。あるケースでは、ラップトップ用の元の充電器を持っていなかったため、ディスプレイをオフにする必要があり、4コアとハイパースレッディングでは、供給された充電器よりも多くの電力を使用したため、バッテリーが低下し、バッテリーが最大10%になるまで、コンピューターはクロック速度を5%遅くしました!(ディスプレイをオフにすると、数日間フルスピードで実行されました)。いかなる場合でも、悪影響はありません。

したがって、適切に設計されたコンピューターであれば、その通りです。適切に設計されていない安価なコンピューターであれば、同僚は正しいかもしれません。一方、あなたは待ち時間の費用対交換用コンピュータの購入費用を考慮するかもしれません。


0

可能であれば、コードを優先度の低いタスクにし、CPUが重いスレッドをGUIとは別にしてください。その後、100%の使用率が得られる可能性がありますが、ユーザーは常に他のタスクを実行して応答性を維持できます。CPU自体は、しばらくの間100%の使用率で実行し続けるように設計されています。そうしないと、CPUは解放されません。エンドユーザーがハードウェアに深刻で危険な変更を加えない限り、何も損傷することはありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.