「マルチコア」フレンドリーではないと主張するプログラム

このフレーズまたは類似のフレーズは、時々発生します。一般的に、マルチコアプロセッサを最大限に活用するように設計されていないと主張するプログラムを指します。これは、特にビデオゲームプログラミングで一般的です。（もちろん、基本的なスクリプトなど、多くのプログラムには並行性がなく、それを必要としません）。

どうすればいいの？多くのプログラム（特にゲーム）は本質的に同時実行を使用し、OSはCPUのタスクスケジューリングを担当しているため、これらのプログラムは本質的に利用可能な複数のコアを利用していませんか？この文脈で「複数のコアを活用する」とはどういう意味ですか？これらの開発者は、実際にOSタスクのスケジューリングを禁止し、アフィニティまたは独自のスケジューリングを強制していますか？（大きな安定性の問題のように聞こえます）。

私はJavaプログラマーなので、抽象化やその他の理由でこれに対処する必要はなかったかもしれません。

良好な同時実行性は、アプリケーションにいくつかのスレッドを投げて最高のものを期待する以上のことを必要とします。プログラムが並外れた並列処理から純粋な順次処理に移行する方法には幅があります。どのプログラムでも、アムダールの法則を使用して、問題またはアルゴリズムがどれだけスケーラブルであるかを表現できます。恥ずかしいほど並列アプリケーションのいくつかの資格は次のとおりです。

• 共有状態はありません。すべての関数は、渡されたパラメーターにのみ依存します
• 物理デバイス（グラフィックカード、ハードドライブなど）へのアクセスなし

他の資格もありますが、これらの2つだけで、特にゲームが複数のコアを利用するのが簡単だと思わない理由を理解できます。1つは、異なる関数が物理学、動きを計算し、人工知能を適用するなど、レンダリングされる世界のモデルを共有する必要があります。2つ目は、このゲームモデルの各フレームをグラフィックカードで画面にレンダリングする必要があります。

公平を期すために、多くのゲームメーカーは、サードパーティ製のゲームエンジンを使用しています。しばらく時間がかかりましたが、これらのサードパーティのゲームエンジンは、以前よりはるかに並列になりました。

効果的な同時実行性に対処するには、アーキテクチャ上の大きな課題があります

並行性は、バックグラウンドでのタスクの実行から並行性の完全なアーキテクチャサポートまで、多くの形式をとることができます。一部の言語では、ERLANGなどの非常に強力な同時実行機能が提供されますが、アプリケーションの構築方法については非常に異なる考え方が必要です。

すべてのプログラムが完全なマルチコアサポートの複雑さを実際に必要とするわけではありません。そのような例の1つは、税務ソフトウェア、または任意のフォーム駆動型アプリケーションです。あなたの時間のほとんどがユーザーが何かをするのを待つことに費やされるとき、マルチスレッドアプリケーションの複雑さはそれほど有用ではありません。

一部のアプリケーションは、Webアプリケーションなど、より厄介な並列ソリューションに適しています。この場合、プラットフォームは恥ずかしいほど並行して開始され、スレッドの競合を課す必要はありません。

要点：

複数のスレッド（つまりコア）を利用しないことで、すべてのアプリケーションが実際に損害を受けるわけではありません。それによって傷つけられるものについては、計算が並列処理に適していないか、それを調整するためのオーバーヘッドがアプリケーションをより脆弱にする場合があります。残念ながら、並列処理はまだうまくいくべきほど簡単ではありません。

多くのプログラム（特にゲーム）は本質的に並行性を使用していますが、

いいえ、実際は逆です。ほとんどのアプリはシングルスレッドマインドセットで記述されており、開発者は並行性をサポートするために必要な変更を行っていません。

C、C ++、およびC＃では、新しいスレッドやプロセスを開始するようにアプリケーションに明示的に指示する必要があります。

あなたはスレッドのスケジューリングに集中しすぎており、潜在的なスレッド内のデータ処理に十分ではないと思います。スレッドやプロセス間でデータを共有するには、何らかの同期が必要です。複数のスレッドを使用するようにアプリケーションを変更しても、その同期が適切に行われないと、コード内のバグを追跡するのが非常に難しくなる可能性があります。

私が取り組んできたマルチスレッドアプリケーションの場合、通常はディスパッチについては心配せず、データの同期についてのみ心配しました。ディスパッチについて心配しなければならなかったのは、誤ったデータ同期のために競合状態を追いかけていたときだけでした。

一般に、アプリケーションが複数のコアを使用できないと言った場合、データ操作を保護するための同期が行われていないことを意味します。

これは、複数のスレッドに関するものであるため、複数のコアに関するものではありません。OSは、任意のコアで実行するスレッドをスケジュールする場合があり、このスケジュールは、スケジュールされているプログラムに対して透過的です。ただし、多くのプログラムは複数のスレッドを使用して記述されていないため、一度に1つのコアでしか実行できません。

なぜシングルスレッドのプログラムを書くのですか？それらは書くのがより簡単で、デバッグもより簡単です：複数の事柄が一度に起こり、お互いの方法で可能になるのではなく、ある事柄が次々に起こります。または、プログラムがマルチコアマシンをターゲットにしていない可能性があります（古いゲームの場合のように）。場合によっては、コンテキスト切り替えとスレッド間の通信のオーバーヘッドが並列実行によって得られる速度を上回る場合、マルチスレッドプログラムはシングルスレッドバージョンよりも遅く実行される可能性があります（プログラムの一部は並列​​化できない場合があります）。

これは完全な答えではありません。それは警告物語です。

ある日、並行プログラミングコースの学生に並列クイックソートを見せようと思いました。クイックソートはうまく並列化すべきだと思いました。2つのスレッドを使用しました。シングルコアコンピューターで実行しました。結果は次のとおりです。

• シングルスレッドバージョンの場合は14秒。
• 2スレッドバージョンの場合は15秒。

これは私が期待したことについてでした。

次に、新しいデュアルコアマシンで試しました。

• シングルスレッドバージョンの場合は11秒。
• 2スレッドバージョンの場合は20秒。

2つのスレッドは、残りのタスクのキューを共有しました。キューオブジェクトのフィールドは、一方のコアのキャッシュと他方のキャッシュとの間で前後にシャッフルされていたようです。