分散コンピューティングとスレッド

Question

分散コンピューティングとスレッド化はどの程度似ていますか？まったく逆の結論に達する2つの論文を見つけました。

＆quot;マルチスレッドはネットワークよりも簡単です。スレッド化が簡単であり、ネットワークコードに似ている方法

http://software.intel.com/file/14723

（これは、カプセル化後、これら2つのアプローチを同じコードで実行できるほど類似しているという印象を与えますが、おそらく間違っています）

＆quot;分散コンピューティングに関する注意事項＆quot;

http://research.sun.com/techrep/1994/abstract -29.html

（そして、これにより強い区別が付けられます）

真実はどこかにあると確信しています。黄金とはどういう意味ですか？これらの2つのパラダイムを統合する技術はありますか？または、ネットワークと同時実行性の根本的な違いのために、そのような試みは失敗しましたか？

Answer 1

これらが非常に似ていることは一度もありません。この投稿の目的のために、「ノード」を定義しましょう。 1台のマシンで実行される1つのハードウェアスレッドになります。したがって、クアッドコアマシンは4つのノードであり、4つのシングルプロセッサボックスのクラスターも同様です。

通常、各ノードは何らかの処理を実行しており、何らかのノード間通信が必要になります。通常、この通信の最初のインスタンスは、ノードに何をすべきかを伝えています。この通信には、共有メモリ、セマフォ、共有ファイル、名前付きパイプ、ソケット、リモートプロシージャコール、分散COMなどを使用できます。しかし、共有メモリとセマフォを使用するのが最も簡単なものは、通常ネットワーク経由では使用できません。共有ファイルは利用可能かもしれませんが、一般的にパフォーマンスは良くありません。ソケットは、より洗練されたメカニズムではなく、ネットワーク上で最も一般的で最も柔軟な選択肢になる傾向があります。その時点で、遅延、帯域幅、パケット損失、ネットワークトポロジなど、ネットワークアーキテクチャの詳細に対処する必要があります。

作業のキューから開始する場合、同じマシン上のノードは単純な共有メモリを使用して実行することができます。ロックなしで作成することもでき、シームレスに機能します。ネットワーク上のノードで、キューをどこに配置しますか？一元化すると、そのマシンは非常に高い帯域幅コストを被る可能性があります。配布しようとすると、非常に複雑になります。

一般的に私が見つけたのは、このタイプの並列アーキテクチャに取り組む人々が、解決するために恥ずかしいほど並列の問題を選ぶ傾向があるということです。レイトレーシングが思い浮かびます。ジョブの分散を除き、ノード間通信はそれほど必要ありません。確かにこのような多くの問題がありますが、分散コンピューティングが本質的にスレッド化と同じであることを示唆するのは少し不誠実です。

ここで、純粋なメッセージの受け渡しを使用して、スレッドが「メイン」であると仮定せずに、分散システムと同じように動作するスレッドを作成する場合そして、そう、それらは非常によく似たものになるでしょう。しかし、あなたがしたことは、あなたが分散アーキテクチャを持ち、それをスレッドに実装したふりをしていることです。問題は、スレッド化が真の分散コンピューティングよりもはるかに単純な並列処理の場合であるということです。 2つを抽象化して1つの問題にすることもできますが、より難しいバージョンを選択し、それに厳密に固執することによって可能です。そして、すべてのノードがマシンに対してローカルである場合、結果はそれほど良くありません。特別な場合を利用していない。

Answer 2

コンピューティングの分散は、複数の異なる独立したマシン上で行われ、一般的には特殊なOSが使用されます。マシンの相互接続性がはるかに低いため、データセット全体への迅速でランダムなアクセスを大量に必要とする問題を解決するのは非常に困難です。

一般的に、ノードを問題に割り当ててデータをやり取りする方法を見つけ出す分散コンピューティングの問題を行うには、専門のライブラリが必要です。

各プラットフォームで間違った問題を解決しようとしているため、彼らが異なる結論に達しているのではないかと本当に思っています。一部の問題は、高度に相互接続されたマシンに非常にうまく当てはまり、本当に強力なスーパーコンピューターの恩恵を受けることができます。その他の問題は、単純に分散されたモデルで対処できます。一般に、スーパーコンピューターは幅広い問題を解決できますが、はるかに専門的で高価です。

Answer 3

違いはスレッドの共有状態に戻ったようで、プロセスはメッセージを渡します。

いずれかを選択する前に、アプリの状態を維持する方法を決定する必要があります。

状態の共有は簡単に開始でき、すべてのデータと変数がそこにあります。ただし、デッドロック/競合状態が発生すると、変更/スケーリングが困難になります。

メッセージの受け渡し（Erlangなど）には設計に異なるアプローチが必要です。最初から並行処理の機会を考える必要がありますが、各分散プロセスの状態は分離されているため、ロック/競合の問題に対処しやすくなります。

Answer 4

スレッドとプロセスを比較するよりも、プロセスを分散コンピューティングアプローチと比較する方がはるかに便利だと思います。スレッドは単一のプロセス内に存在し、同じデータと同じメモリを共有します。これは、いくつかのマシンでは不可能です。一方、プロセスには独自のメモリがありますが、場合によっては別のプロセスとまったく同じデータが含まれています（たとえばfork（）の後）。これはネットワーク経由で実現できます。

この類推にさらに重みを加えるのは、プロセス間通信に使用される多くのツールがネットワーク透過的であるという事実です。よい例は、ネットワークソケットと同じインターフェイスを使用するUNIXソケットです（接続コードを除く）。

Answer 5

はい、開発時のアプローチは非常に似ていますが、それぞれの使用方法は非常に異なります。私はあなたの考えを非常にはっきりさせません、私が間違っているかどうかを教えてください：分散コンピューティングについて話すとき、同じアプリケーションで複数のコンピューターまたはサーバー処理コードを想定していますが、マルチスレッドについて話しているとき同じコンピューターでアプリケーションの異なるスレッドを同時に処理することについて話している。 インターネットにあるWebサービスにアクセスする1つのアプリケーションで、分散コンピューティングの例と考えることができます。同じアプリで動作する2つの異なるコンピューターがあります。

マルチスレッドの例が必要な場合は、1つの大きな素数を見つけようとしているアプリケーションを考えてください。アプリケーションでマルチスレッドを使用しない場合、アプリケーションは次の素数を計算しているときに（ライフタイム以上になる可能性があります）、アプリケーションで他の何かを表示または実行できません。計算中に応答していません。

これらを混在させることもできます。より複雑な例として、同じアプリケーションから同時にマルチスレッドを使用して異なるWebサービスに同時にアクセスできます。これは、接続していない場合でもアプリケーションを応答させるためです。サーバーの1つ。

Answer 6

これら2つのドキュメントは簡単に比較できないと思います。 Intelのドキュメントはスレッド処理の一種であり、ネットワークコンピューティングとの類似点を見つけることで説明しようとしていますが、これは少し奇妙で誤解を招く恐れがあります。なぜスレッドを提示するこのような方法を選んだのかはわかりませんが、おそらく、スレッドよりも知られているか、少なくとも認識されているネットワークに精通した人々を狙ったのでしょう。

一方、Sunのドキュメントは、分散プログラミングに関連するすべての困難を描いた深刻な記事です。私ができることは、彼らがそこで言っていることを単に確認することです。

私の意見では、オブジェクトがリモートであるという事実を隠そうとする抽象化は、通常非常に悪いパフォーマンスにつながるため、有害です。プログラマは、オブジェクトを効率的に呼び出すことができるように、オブジェクトのリモート性を認識する必要があります。