マルチプラットフォームマルチスレッド：本当の課題は何ですか？

SDLのようなライブラリは、スレッド化のためのクロスプラットフォームラッパーAPIを提供しますが、これが非常に異なるプラットフォーム（デスクトップ/モバイル）でのゲームの簡単な開発に直接つながると考えるのは単純だと思います。

次の点を考慮して、この方法で開発に取り組む最良の方法は何ですか（クロスプラットフォームスレッドAPIが与えられた場合）：

• 異なる数のコア
• コアごとに大幅に異なる処理機能
• 一般的に異なるシステムアーキテクチャ、たとえば。キャッシュ、RAM、およびI / Oアクセスのさまざまなレイテンシ

これを行う唯一の方法は、サポートする各デバイスごとに実行できるスレッド数を評価し、最小公分母が何であるかを調べることだと感じています。ただし、これにより、利用可能な処理スループットの合計量に関して、私はまだ暗闇の中に残ります。これを効果的に行う唯一の方法は、開発中、サポートするつもりの最低スペックのモバイルデバイス向けに積極的に開発することだけだと思いますか？-すなわち、最小公分母？これで大体十分でしょうか？それともこれ以上のものがありますか？

編集：私の質問がまだ完全に回答されているとは思わないので、他の人がこれについてさらに経験を提供してください。

「マルチスレッドの問題」について話していますが、実際にどのような問題について話していますか？ある意味では、存在しないかもしれない幻の問題を引用しています。本当の課題は、あなたが自分で作るものです-ハードウェアから最後の一滴の力を完全に落とすことに絶対に決心しているなら、それはハードウェアを使用して最高の効果をもたらしますが、最も強力なマシン間のギャップも広げますそして、最も強力ではありません。これが意味するのは、PS3を最大限に活用するゲームがある場合（たとえば）、とにかく安価な携帯電話で実際に実行することはできないため、問題は「どうすれば1つのプログラムを入手できますか」 「非常に異なるハードウェアで動作するように」が「異なるゲームのハードウェアで動作するように、1つのゲームのアイデアをいくつかの異なる方法で実装する方法」になります。

SDLのようなライブラリは、スレッド化のためのクロスプラットフォームラッパーAPIを提供しますが、これが非常に異なるプラットフォーム（デスクトップ/モバイル）でのゲームの簡単な開発に直接つながると考えるのは単純だと思います。

ゲームの簡単な開発-確かに。最適なマルチスレッド、いいえ。ただし、ゲームを作成するためにマルチスレッドは必要ありません。高性能のものを作成するには、確かに役立ちます。しかし、多くの優れたゲームは単一のスレッドで実行されます。

次の点を考慮して、この方法で開発に取り組む最良の方法は何ですか（クロスプラットフォームスレッドAPIが与えられた場合）：

• 異なる数のコア
• コアごとに大幅に異なる処理機能
• 一般的に異なるシステムアーキテクチャ、たとえば。キャッシュ、RAM、およびI / Oアクセスのさまざまなレイテンシ

システムをスレッドに割り当てようとする代わりに、タスクをスレッドに割り当てます。各タスクに実行に必要なデータを与え、利用可能なハードウェアにタスクをファームします。通常、さまざまなコアまたはプロセッサを抽象化するためのある種のスレッドプールと、タスクのキューを持ち、スレッドが前のタスクを終了したことを通知したときにさまざまなスレッドにそれらを渡すタスクマネージャーがあります新しいものの準備ができています。より多くのコアを備えたハードウェアは、明らかにタスクをより迅速に完了し、より迅速にレンダリングできるようになります。異なる特性を持つシステムで最適に動作するようにこのシステムを特化することは、高度な最適化の問題になりますが、特定のヒューリスティックに基づいている場合があります（たとえば、

ただし、ゲーム機能を個別のタスクに分解することは非常に複雑な問題であり、パフォーマンスが必要であることが確実でない限り、努力する価値がないことが多いため、ほとんどの人はそれを試みさえしません。

さらにいくつかの読書：

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php-「データ並列」セクションを参照してください。このモデルでは、データは複数の同一のタスクに分割され、個々のスレッドにファームアウトされます。

http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/-非常に高密度で、ゲームレベルではなくOSレベルで説明します。

http://drdobbs.com/high-performance-computing/216500409-ゲーム固有ではありませんが、タスクを分割する方法を説明するという点で完全に関連しています。

http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3-このインタビューの半分は、彼らがタスクベースのシステムにどのように移行したかについての逸話です。

モバイルゲームを開発したとき、最初に「ゴールド」バージョン（つまり、完全に機能するゲーム）を開発し、次にそれを3つのメジャーバージョン（大画面、中画面、小画面）に分割しました。これらはさらに11のバージョンに変換されました：要求の多いグラフィックス（読み取りに多くのメモリ/ CPUが必要）vsロープロファイルなど（いくつかの「特別なプラットフォームバージョンもありました」）

最大の問題は（特に私の仕事でした）必要なプラットフォームを分離し、それらのバージョンとそれらの作成方法を決定することでした（すなわち、大画面だがロープロファイルは大画面/ハイプロファイルのダウングレードバージョンである必要がありますか中型スクリーン/ロープロファイルは、大画面を作りました？）。

もちろん、これを念頭に置いてコーディングしたので、ゲームは画面サイズに非常に緩やかに結びついていました。

HTH

[編集]つまり、ターゲットプラットフォームを異なる品質（1コア、2コア、1コアで2倍の速度）に分割する必要があるということです。そして、必要な仮想ターゲットの数を決定します（たとえば、 「1つのみ」または「低、中、高」）次に、すべてのプラットフォームをそれぞれの「品質」に配置し、品質ごとに最低の分母を取り、コードを「移植」して、それらの要件に準拠するようにします（つまり、動作し、高速です）十分な）。

かなりの当て推量でこれを行わなければならないように思えるかもしれませんが、最悪のプラットフォームで最低の品質をすでに見つけることができます。私は次の品質をすべて前者と少なくとも「2倍」選択しますが、これはおそらく3〜4個の「品質」以上のものを生成しないでしょう。コードがゴールドバージョンから移植された場合、パフォーマンスが十分でないプラットフォームは、より低い「品質」にレトログレードして、スピードを上げることができます。新しいプラットフォームを適切な品質で簡単に配置することもできます。

これを行う唯一の方法は、サポートする各デバイスごとに実行できるスレッド数を評価し、最小公分母が何であるかを調べることだと感じています。

必ずしもそうではありません-より動的な解決策の希望があるかもしれませんが、これはあなたが解決しようとしている実際の問題（もしあれば）に依存します。あなたはあなたの質問に少しあいまいですので、私の答えもあいまいでなければなりません。

実行する予定のプラットフォームのグループにAPIを介したハードウェア列挙の機能がある場合、そのインターフェイスを使用して、システムが処理できるスレッドの最大数を検出し、それをアプリケーションのスレッド数の基準として使用できます作成する必要があります。ここでの唯一の課題は、これらのAPIを見つけることです。OSレベルに移動するか、サードパーティのライブラリを検索するか、クロスプラットフォームSDK / APIを使用するかはユーザー次第であり、サポートしようとしているプラ​​ットフォームによって異なります。

次の点を考慮して、この方法で開発に取り組む最良の方法は何ですか（クロスプラットフォームスレッドAPIが与えられた場合）：

different numbers of cores
vastly different processing capabilities per core
A generally different systems architecture with eg. different

キャッシュ、RAM、I / Oアクセスのレイテンシ

私の意見では、これらはどれもあなたの関心事ではないはずです。あなたの懸念はあなたのゲームを構築することです。ボトルネックにぶつかり、特定のプロセッサー集中タスク用に別のスレッドを生成する方が良いと判断した場合、スレッドを生成し、OSおよび他の低レベルのソフトウェアにハードウェアを操作してスレッドを処理する方法を決定させます。