コンパイルされたコードのユニットをクラウド内のさまざまなマシンに分散させるクラウドベースのコンパイラを作成することは、実用的な利点でしょうか? コンパイル直後にアプリ内でサービスとしてのソフトウェア アーキテクチャを取得するメリットはありますか?それとも固有のレイテンシにより、そのようなアプローチは実用的ではありませんか?
9 に答える
私があなたの主張を誤解したのか、それとも他の回答が誤解したのかはわかりません。ある種の自動並列化タスクについて話しているのですか? これまでの回答は、分散コンパイル、つまりクラウドを使用してコンパイル時間を短縮することについて話しているようです。代わりに、クラウド コンピューティング リソースを対象とするコンパイラについて話していると思いました。
実際に分散コンパイルについて話しているのであれば、明らかに distcc のようなものが必要なことを行います。
分散アーキテクチャを対象とするコンパイラが役立つかどうかについて、もっと興味深い (IMHO) 質問をしている場合、私の答えは圧倒的に「はい」です。ただし、実現可能性が問題の中心にあります。遅延自体は問題ではありませんが、一貫性 (つまり、すべてのユニットの正しいバージョンが配置されていることの確認) と適切なヒューリスティックを持つことが問題になります。
調べるのに最適な場所は、おそらく Occam プログラミング言語でしょう。これは、トランスピューターをターゲットにしていました。これは、最近私たちが興味を持っている種類の分散システム アーキテクチャと完全に異なるものではありませんでした。オッカムに続くいくつかの研究が、最新技術が何であるかについての有用な手がかりを提供する可能性があると私は信じています.
最も一般的なUNIXコードの分散コンパイルにdistcc使用できます。make -jコードの大きなチャンクを定期的にコンパイルすると、大幅な高速化が得られる可能性があります... afaik samba(無料のsmb実装)開発者はこれを使用します。distcc前処理とマスターマシンへのリンクを残して、分散された方法でコンパイルフェーズのみを実行します。
「クラウド」との相互作用はレイテンシーを引き起こす可能性がありますが、それでもより複雑なc++コードでは非常に役立つと思います。100を超えるコンパイルユニット(fe .cppファイル)がある場合は、著しく高速化される可能性があります。
私はそのようなシステムを使用したことがありますが、クラウドではなく、ローカル クラスターで動作しました。しかし、原則はまったく同じです。残念ながら、それが何と呼ばれていたかは思い出せませんが、ソース ファイルが部門内の他の PC に配布されるのを見るのは楽しかったです。
編集: IncrediBuildと呼ばれていました。
それは非現実的だと思います。今日のハードウェアは、小規模および中規模のプロジェクトのコンパイルを適切な時間で実行できます。マルチコア CPU ではなおさらです。
唯一の例外は、オペレーティング システム全体 (Debian など) をソースからビルドする場合です。このようなアプリケーションでは、ビルド ファームが広く使用されています。ただし、ビルド ファームが必要なユーザーは通常、自分でファームを作成でき、クラウドに移動する必要はありません。
GridGain上でJUnitテストを実行する素晴らしいデモを見てきましたが、GridGainはクラウドで実行できます。
ただし、コンパイラがクラウドにあることにはあまり価値がありません。
はい、質問してくれてありがとう、私もこの分野で研究しています。実際にはそれは非常に理にかなっており、http://www.cloudcompiling.com/に存在しますが、私が見る限り、それはまだトップ10のサービスにはほど遠いです。
レイテンシーはコードのアップロードのみにあるため、開発者が良好な接続で作業していて、それほど遠くない場合(ネットワークホップと「良好な」ホップの観点から)、問題にはなりません。
クラウドでのレイテンシーはクラウドプロバイダーの問題です。それがクラウドプロバイダーである場合は、適切なバランス戦略が必要です。
場合によります。以前は、3 ~ 4 時間かかる古い C++ ベースのコンパイルがありました。そのような場合、コンパイルをオフロードすると非常に便利です。しかし、C++ プロジェクトでは、これはさらに可能性が低くなります。
C# または Java を使用すると、コンパイル時間が大幅に短縮されるため、それほど重要ではない可能性があります。