クラスタマシンで光速ビルドせよ

どうせ、4,5台のPCを掻き集めてきたって、せいぜい3倍のパフォーマンスしか出ません。

しかも、1年も経てばクラスタノードを増やすより最新マシンでリプレースした方が性能が上がるんです。

そんな金食い虫で何をやろうっていうんです?

準公共グリッド発電所につないだ方が、よほど世のため人のためでしょう。きっと宇宙人とのコンタクトも成功しますよ。

ただ、5台くらいのクラスタマシンで是非是非実践してほしいことがあります。それは分散ビルドです。並列コンパイルです。

開発環境の優劣や、プリコンパイル済みヘッダの有無など不毛な議論はもうやめましょう。人類はソフトウェアクライシスに勝利しました。際限なく増大するLOCに数々の発明あるいは天才による方法論の編み出しによって回避可能な一問題にすぎなくなったのです、規模の問題は。

解決できていない部分問題もあります。それは、ビルドにかかる時間と、複雑性の問題です。複雑性の問題は、最適解はむりでも近似的解法がいずれ編み出されます。時間の問題です。ゲノム解析というリバースエンジニアリング分野に豊富な資金が流れ込み続ければあっという間です。

残念なことに、ビルド所要時間ムーアの法則が実質的に機能していません。おかしいですね。ソースコードの肥大化速度はムーアの予測よりも充分遅いはずです。

固定ディスクが二次記憶の主役になってしまってからつい忘れがちになりますが、ビルドの所要時間の大部分を占めるのはディスクアクセスであることを思い出してください。
#ベテランの趣味プログラマならカセットテープの巻き戻し時間!

そうです。マシンが2倍速くなっても、ディスク速度はちっともはやくなっていないのです。

巨大なビルドではコンパイル作業の並列化する余地は大きいはずです。見落としがちなのは、巨大ビルドでは依存関係の洗い出しや実効順序を決めるトポロジカルソート自体も相当に重い処理であるということです。

MS製.NET開発環境やJava周辺では当たり前の技術でしょうが、お手持ちのビルドマシンは、クラスタ化されてますか?ナイトリービルドだから1台で充分なんて呑気なことを言っていると競争相手に負けますよ。

間抜けなのは、MPI対応などと謳ってソースから自動的に並列処理を洗い出してくれたりするコンパイラそれ自身が、分散ビルドに対応できないことです。ビルドシステムやmakeだけが対応すればよいという問題ではありません。真のパフォーマンスとは全体最適化が必須なのです。(ほんとか?)

メモリン:

make -j

リンクル:
インテル開発環境製品

SN-DBS – Distributed Build System