プログラムが特定の最小数のCPUコアを必要とするのはなぜですか？

N個未満のコアを持つCPUで実行すると正常に動作しないコード（またはコードではなく完全なソフトウェア）を作成することはできますか？明示的にチェックせず、意図的に失敗することなく：

IF（noOfCores <4）その後、意図的に適切に実行されない

私はゲームの（Dragon Age：Inquisition）最小システム要件を調べていますが、それは最低4コアCPUを示しています。多くのプレイヤーは、2コアCPU および2つの物理コアと2つの論理コアを備えたIntel Core i3では動作しません。そして、それは計算能力の問題ではありません。

私の理解では、スレッドはOSによってCPUから完全に分離されています。

ただ物事をクリアするために：

私はありません「私はコードからCPUコアの数を調べると、意図的に失敗することはできますか？」尋ねます ...そのようなコードは意図的ではありません（計算能力を必要とせずに、プログラムを実行するためにより高価なCPUを購入せざるを得ません）。たとえば、コードが4つのスレッドを持ち、同じ物理コアで2つのスレッドが実行されると（システム情報を明示的に確認して意図的に失敗することなく）失敗するようにしています。

要するに、複数のコアから来る追加の計算能力を必要とせずに、複数のコアを必要とするソフトウェアが存在できるのでしょうか？N個の個別の物理コアが必要です。

コアアフィニティを不注意に使用すると、「偶然に」これを行うことができる場合があります。次の擬似コードを検討してください。

• スレッドを開始する
• そのスレッドで、それが実行されているコアを見つけます
• CPUアフィニティをそのコアに設定します
• 計算量の多いものを実行し始める/永遠にループする

2コアCPUでそれらの4つを起動すると、コアアフィニティ設定に問題が発生するか、使用可能なコアを占有する2つのスレッドと、スケジュールされない2つのスレッドが発生します。コアの合計数を明示的に尋ねることはありません。

（長時間実行されるスレッドがある場合、一般にCPUアフィニティを設定するとスループットが向上します）

ゲーム会社が正当な理由もなくより高価なハードウェアを購入することを「強制」しているという考えは、あまり妥当ではありません。顧客を失うだけです。

編集：この投稿には33の賛成票があります。これは教育を受けた当て推量に基づいているため、かなりの量です。

人々はDA：Iをデュアルコアシステムでひどく実行しているようです：http : //www.dsogaming.com/pc-performance-analyses/dragon-age-inquisition-pc-performance-analysis/その分析ハイパースレッディングを有効にすると、状況が大幅に改善されると述べています。HTは命令発行ユニットまたはキャッシュを追加しないため、1つのスレッドがキャッシュストール中に別のスレッドの実行を許可するだけであるため、純粋にスレッドの数にリンクされていることを強く示唆しています。

別のポスターは、グラフィックドライバーの変更が機能すると主張しています。http：//answers.ea.com/t5/Dragon-Age-Inquisition/Working-solution-for-Intel-dual-core-CPUs/td-p/3994141 ; グラフィックスドライバーがスカムとビラニーの惨めなハイブになる傾向があることを考えると、これは驚くことではありません。悪名高いドライバーの1つのセットには、QUAKE.EXEから呼び出された場合に選択される「修正＆低速」モードと「高速＆不正」モードがありました。見かけのCPUの数が異なると、ドライバーの動作が異なる可能性があります。おそらく（推測に戻ると）別の同期メカニズムが使用されます。スピンロックの誤用？

「ロックおよび同期プリミティブの誤用」は、非常に一般的なバグの原因です。（これを書いている間に職場で見ているは​​ずのバグは、「印刷ジョブの終了と同時にプリンター設定を変更するとクラッシュする」です）。

編集2：コメントは、OSがスレッドの枯渇を回避しようとしていると述べています。ゲームにはスレッドに作業を割り当てるための独自の内部擬似スケジューラがあり、グラフィックカード自体にも同様のメカニズムがあることに注意してください（事実上、独自のマルチタスクシステムです）。それらのいずれかでのバグの可能性またはそれらの間の相互作用は非常に高いです。

http。非プリエンプティブシステム。状況は改善されましたか？おそらくない。

アプリケーションは4つのタスクを並列スレッドで実行し、それらがほぼ同時に終了することを期待しているため、4つのコアが必要になる場合があります。

すべてのスレッドが別々のコアで実行され、すべてのスレッドがまったく同じ計算ワークロードを持っている場合、それらはほぼ同じ時間で終了する可能性が非常に高い（ただし、保証はほど遠い）。しかし、1つのコアで2つのスレッドが実行されると、コアは常に2つのスレッド間でコンテキストを切り替えるため、タイミングの予測がはるかに難しくなります。

予期しないスレッドタイミングのために発生するバグは、「競合状態」と呼ばれます。

ゲーム開発のコンテキストでは、この種の問題のあるもっともらしいアーキテクチャは、ゲームのさまざまな機能がさまざまなCPUスレッドによってリアルタイムでシミュレートされるものです。各機能が独自のコアで実行される場合、それらはすべてほぼ同じ速度でシミュレートされます。ただし、2つの機能が1つのコアで実行される場合、両方がゲーム世界の他の半分の速度でしかシミュレーションされないため、あらゆる種類の奇妙な動作が発生する可能性があります。

特定のタイミングで実行される独立したスレッドに依存するソフトウェアアーキテクチャは、非常に脆弱であり、並行プログラミングに対する非常に悪い理解の兆候であることに注意してください。これらの種類の問題を防ぐためにスレッドを明示的に同期するために、実質的にすべてのマルチスレッドAPIで利用可能な機能があります。

これらの「最小要件」が、ゲームが実行されないものを表すことはほとんどありません。はるかに可能性が高いのは、それらがそれを下回るとゲームが許容可能なパフォーマンスで実行されないことを表していることです。たとえソフトウェアが技術的に実行できたとしても、シングルコアの1 Ghzボックスで実行しているとき、パフォーマンスが悪いと訴える多くの顧客に対処したいゲーム会社はありません。したがって、彼らはおそらく、許容できるパフォーマンスを提供するよりも少ないコアのボックスでハードに失敗するように意図的に設計しています。

ゲームのパフォーマンスにおける重要な指標の1つは、フレームレートです。通常、1秒あたり30または60フレームで実行されます。これは、ゲームエンジンが一定の時間内にゲーム状態から現在のビューをレンダリングする必要があることを意味します。60 fpsを達成するには、これを行うのに16ミリ秒以上かかります。ハイエンドグラフィックスを使用したゲームはCPUに非常に制約されているため、高品質（より多くの時間を必要とする）をプッシュしようとすることと、この時間の予算内に留まる必要性との間には大きなやり取りがあります。したがって、各フレームの時間バジェットは非常に厳しいです。

時間の予算が限られているため、開発者は1つ以上のコアへの排他的アクセスを理想的に望んでいます。また、彼らはおそらく、その時間予算で行わなければならないものであるため、コアでレンダリング処理を実行できるようにしたいと考えていますが、世界の状態を計算するなどの他の処理は別のプロセスで発生します侵入する。

理論的には、これらすべてを単一のコアに詰め込むこともできますが、そうするとすべてが非常に難しくなります。突然、ゲームのすべての状態が十分に速く発生し、レンダリングが発生することを確認する必要があります。OSに「スレッドBが何をするかに関係なく、スレッドAは16ミリ秒でXの作業量を完了する必要がある」と理解する方法がないため、2つのソフトウェアスレッドにすることはできません。

ゲーム開発者は、新しいハードウェアを購入することに興味がありません。彼らがシステム要件を持っている理由は、低価格のマシンをサポートするコストはそれだけの価値がないからです。

スリープしない3つのリアルタイムスレッドと1つの他のスレッド。コアが4つ未満の場合、4番目のスレッドは実行されません。リアルタイムスレッドが終了するために、4番目のスレッドがリアルタイムスレッドの1つと通信する必要がある場合、コードは4コア未満で終了しません。

明らかに、リアルタイムスレッドがスリープ状態を許可しないもの（スピンロックなど）を待機している場合、プログラム設計者は台無しになります。

まず第一に、ソフトウェアスレッドはハードウェアスレッドとは関係なく、しばしば混同されます。ソフトウェアスレッドは、プロセスコンテキスト内でディスパッチして実行できるコードの一部です。ハードウェアスレッドは主にOSによって管理され、通常のプログラムについて話すときにプロセッサのコアにディスパッチされます。これらのハードウェアスレッドは、負荷に基づいてディスパッチされます。ハードウェアスレッドディスパッチャーは、ほぼロードバランサーのように機能します。

しかし、ゲーム、特にハイエンドのゲームに関しては、ハードウェアスレッドがゲーム自体によって管理されるか、ゲームがハードウェアスレッドディスパッチャーに何をするかを指示することがあります。これは、すべてのタスクまたはタスクのグループが、通常のプログラムのように同じ優先順位を持っているわけではないためです。ドラゴンエイジは、ハイエンドのゲームエンジンを使用したハイエンドのゲームスタジオから来ているため、「手動」ディスパッチを使用し、コアの数が最小システム要件になると想像できます。コアが1つまたは2つしかないマシンで実行されている3番目の物理コアにコードを送信すると、プログラムがクラッシュします。

virtualizeを使用して物理コアよりも多くの仮想コアを持つことが可能であり、ソフトウェアは仮想化で実行されていることを認識せず、代わりにそのような多くの物理コアを持っていると考えるため、このようなソフトウェアは不可能だと思います。

つまり、N個未満のコアで常に停止するソフトウェアを作成することはできません。

他の人が指摘したように、特に使用されているOSとコードが<Nプロセッサで実行される場合の競合状態に対する保護がほとんどない場合、潜在的にチェックできるソフトウェアソリューションがあります。実際のトリックは、N個未満のプロセッサがある場合に失敗するが、N個のプロセッサがあるが、N個未満のプロセッサに作業を割り当てることができるOSがある場合に失敗しないコードです。

3つのスレッドが何らかの処理（バックグラウンドの生成またはNPCの動きの生成）を行い、イベントを4番目のイベントに渡します。4番目のスレッドがすべてのイベントを取得しない場合（コアでスケジュールされていないため）、ビューモデルは正しく更新されません。これは散発的にしか発生しない場合がありますが、これらのコアはいつでも利用可能である必要があります。これは、常に高いCPU使用率が表示されない理由を説明するかもしれませんが、ゲームはとにかく適切に動作しません。

ジョシュアは正しい道を進んでいると思いますが、それは結論ではありません。

できる限り多くのことを行うために記述された3つのスレッドがあるアーキテクチャがあるとします。パフォーマンスを維持するために、これらのスレッドは何の制御も解放しません。Windowsタスクスケジューラからの遅延の危険を冒したくありません。4つ以上のコアがある限り、これは正常に機能しますが、そうでないとひどく失敗します。

一般に、これは悪いプログラミングですが、ゲームは別の問題です。すべてのハードウェアで劣っているデザイン、または十分に優れたハードウェアで優れているデザイン、または劣ったハードウェアゲーム開発者が通常選択する障害のいずれかを選択する場合ハードウェアが必要です。

Is it possible to write code (or complete software, rather than a piece of code) that won't work properly when run on a CPU that has less than N number of cores?

絶対に。リアルタイムスレッドの使用は、これが可能であるだけでなく、ジョブを完了するための望ましい方法（そして、多くの場合、唯一の正しい方法）である状況の良い例です。ただし、通常、リアルタイムスレッドはOSカーネルに限定されます。通常、ある種のハードウェアイベントが定義された期間内に処理されることを保証する必要があるドライバーの場合です。通常のユーザーアプリケーションではリアルタイムスレッドを使用しないでください。また、Windowsユーザーモードアプリケーションでリアルタイムスレッドを使用できるかどうかもわかりません。一般に、オペレーティングシステムは、特定のアプリケーションがシステムの制御を引き継ぐことができるため、ユーザーランドからこれを行うことを意図的に不可能にします。

ユーザーランドアプリケーションについて：実行するために特定の数のスレッドをチェックすることは、必ずしも意図的に悪意があるという仮定は正しくありません。たとえば、コアを必要とする、実行時間の長い、パフォーマンス重視のタスクを2つ実行できます。CPUコアの速度に関係なく、他のスレッドとコアを共有すると、スレッドの切り替えによって生じる通常のペナルティに加えて、キャッシュスラッシングによる深刻で許容できないパフォーマンスの低下が生じる可能性があります（かなり重大です）。特にゲームの場合、これらのスレッドのそれぞれがそれぞれの特定のコアでのみアフィニティを持つように設定し、他のすべてのスレッドがこれらの2つのコアでアフィニティを持たないように設定します。これを行うには、しかし、あなたは

スレッドの数がコアの数を超えると、スピンロックを使用して、ロック競合が目立つ量のコードがひどく実行されます（ゲームのようなアプリケーションの場合、「動作しない」と言えます）。

たとえば、4つのコンシューマスレッドにサービスを提供するキューにプロデューサスレッドがタスクを送信するとします。コアは2つしかありません。

プロデューサーはスピンロックを取得しようとしますが、他のコアで実行されているコンシューマーが保持します。プロデューサーがスピンしている間、2つのコアはロックステップを実行しており、ロックが解放されるのを待っています。これはすでに悪いことですが、それが得るほど悪くはありません。
残念ながら、コンシューマスレッドはタイムクォンタムの終わりにあるため、プリエンプトされ、別のコンシューマスレッドがスケジュールされます。ロックを取得しようとしますが、もちろんロックが取得されるため、2つのコアが回転し、発生する可能性のない何かを待機しています。
プロデューサースレッドはそのタイムスライスの終わりに到達してプリエンプトされ、別のコンシューマーが起動します。繰り返しますが、2人のコンシューマーがロックの解放を待っています。さらに2つのタイムクォンタムが経過するまで、ロックは発生しません。
[...]最後に、スピンロックを保持していた消費者がロックを解除しました。他のコアで回転している人はすぐにそれを取得します。別のコンシューマスレッドである可能性は75％（3対1）です。つまり、プロデューサーがまだ停止している可能性は75％あります。もちろん、これは消費者も失速することを意味します。プロデューサーがタスクを要約しないと、彼らは何の関係もありません。

これは、スピンロックだけでなく、あらゆる種類のロックで原理的に機能しますが、スピンロックでは壊滅的な影響が顕著になります。これは、CPUが何も達成せずにサイクルを焼き続けるためです。

上記に加えて、プログラマーがアフィニティを最初のコアに設定した専用スレッドを使用するという素晴らしいアイデアを持っていたと想像してください。そのため、RDTSCはすべてのプロセッサーで信頼できる結果を提供します（とにかくそうではありませんが、そう考える人もいます）。

あなたが何を求めているのか理解できればそれは可能ですが、それは非常に悪いことです。

あなたが説明していることの標準的な例は、複数のスレッドによって増分されるカウンターを維持することです。これには、計算能力のほとんどは必要ありませんが、スレッド間の注意深い調整が必要です。一度に1つのスレッドのみがインクリメントを実行する限り（実際には読み取りとそれに続く書き込みと書き込みが続く）、その値は常に正しいです。これは、1つのスレッドが常に正しい「前の」値を読み取り、1つのスレッドを追加して正しい「次の」値を書き込むためです。2つのスレッドを同時にアクションに入れると、両方が同じ「前の」値を読み取り、増分から同じ結果を取得し、同じ「次の」値を書き込みます。カウンタは、2つのスレッドがそれぞれそれを実行したと考えていても、事実上1回だけインクリメントされます。

タイミングと正確さの間のこの依存関係は、コンピューターサイエンスが競合状態と呼ぶものです。

多くの場合、競合状態は、同期メカニズムを使用して、共有データの一部を操作するスレッドがアクセスのために並んでいることを確認することで回避されます。上記のカウンターは、このために読み取り/書き込みロックを使用する場合があります。

Dragon Age：Inquisitionの内部設計にアクセスできなければ、誰でもできるのは、なぜそのように振る舞うのかを推測するだけです。しかし、私は私自身の経験で見たいくつかのことをベースにしています。

プログラムが調整された4つのスレッドに基づいているため、スレッドが独自の物理コア上でほとんど中断なく実行されるときにすべてが機能する可能性があります。「チューニング」は、開発中に発生した競合状態に起因するバグを緩和するために、コードを再配置したり、戦略的な場所にスリープを挿入したりする形で実現できます。繰り返しますが、これはすべて推測です。しかし、私は数え切れないほど多くの場合、競合状態がそのように「解決」されるのを見てきました。

チューニングされた環境よりも能力の低いものでそのような方法でプログラムを実行すると、コードが迅速に実行されなかったり、コンテキストが切り替えられる可能性が高いため、タイミングの変更が発生します。コンテキストの切り替えは物理的（つまり、CPUの物理コアが論理コアが保持している作業を切り替えている）および論理的（つまり、CPUのOSがコアに作業を割り当てている）方法で行われますが、どちらかが大きく異なる「予想される」実行タイミングになります。それは悪い行動を引き起こす可能性があります。

Dragon Age：Inquisitionが続行する前に十分な物理コアがあることを確認するという単純なステップを踏まない場合、それはEAの責任です。彼らはおそらく、少額のハードウェアでゲームを実行しようとした人たちからの小額の支援活動の電話やメールを費やしているのでしょう。

Windowsにはこのための機能が組み込まれています。関数GetLogicalProcessorInformationはWindows APIにあります。プログラムから呼び出して、コア、仮想コア、ハイパースレッディングに関する情報を取得できます。

したがって、あなたの質問に対する答えは次のとおりです。