Translate

2011年11月2日水曜日

Googleのクラウドコンパイル環境gomaの話を聞く



gomaというのは
Google社内で使ってる分散コンパイル環境を
さす。

前年DevFestではgoの話をしてくれた
鵜飼さんのGDD2011でのテーマだ。
#漢字が難しかったので、この人だけ
#覚えていた


社内でツールなどを作ると、
Googleでは社内評価とかのコメントがもらえるらしく
"goma is tremendous productivity boost!"
「gomaは生産性をあげてくれる」という評価をもらったそうな。

余談だが、Yahoo翻訳にかけると
「アヘンは、相当な生産性後押しです!」と出てきた。
gomaって"アヘン"って意味があるらしい..

セッションで
鵜飼氏はgomaには特に意味はない
と最初に行っていたのはこのことだったのか..

こういう英語ニュアンスギャグを
さりげなくわかる大人になりたかった..

またえいご漬けやり始めようかな..

(追記)
と、書いたのだけど、
海外出張経験のある人にきいたら
アヘン=opium
 でgomaなんていわない
たぶんケシの実を砕いたゴマ状態の粒を
そういう人がいるのかもしれないということだった。
見間違いかなとおもってYahoo翻訳で
再度翻訳しなおしてみたが
まだgoma=アヘンってでてくる
..よくわからない..
まあ本論とは関係ないから
ほっとこうかな...

話の流れは
もともと鵜飼氏はChroniumプロジェクト(Chromeブラウザ)に
入っていてChromeのコンパイルに時間がかかるから
分散コンパイル環境を作ったそうだ。

Googleでは
コーディング、コードレビュー、リポジトリの3つの状態を
くるくる回していて各々の間で各自環境でのビルド・テストしてレビューを
受け、LGTM(Looks goodうんたら)という評価受けたらリポジトリに入って
Buildbotによるテストして、再度デザインドック(設計?)してコーディング..
していく。

Chromeはいろんなプラットフォームで動作させる必要があるので、
buildbotでのテストはいろんな環境のバイナリを作ることになる。

しらべると3ヶ月で10000回、1日で110回、13分に1回コンパイルされる。

土日はGoogle社員も休むので(休むんだ..)
実際は平日200回、これだと7分半で1回になる。

Chrome関連コミュニティのある人がバスの中で
ノートでコンパイルを開始したら
コンパイルの前に電池が切れたという笑い話があるくらい
コンパイルに時間がかかる。

具体的に言えば、
Google社内でよく使うタイプのPC
Xeon 2.67GHz 6コアで93分。

パラレルビルドで対応してみると、
4パラ23分、8パラ16分、12パラで15分と
このあたりでサチってしまう。

これはコンパイルは時間だけでなく
CPUリソースも食うから。

#ドラゴンブックを思い出す..

なので、コンパイル中
だれかがコミットすることはよくある日常茶飯事
なんだって。

こうなるとビルド中のデグレなんてのも
人間だもの
少なくないのだろうなあ..

で世の中にはdistccなる分散コンパイラ
http://code.google.com/p/distcc/
があるので試しに使ってみたそうな。

distccは手元でプリコンパイル処理
(ヘッダファイルとソースをつないだりするやつ)
を分散させずローカルでやるらしい。
1ファイルインクルードファイルが増えると
それを使ってるソース数分、nノードだとさらにn倍され
同じデータを重複して
送信されてしまう。

処理より通信のコストが高いのは当然なので
この通信増は厄介そうなのは聞いていても
なんとなくわかる。

でdistcc-pumpという
プリプロセスもサーバでやっちゃう機能をつけたら
linuxカーネルコンパイルで50%、Sambaコンパイルで
200%も向上したらしい。

ただ、distccもそうだけどdistcc-pumpは
十分な数のサーバを正しくセットアップする必要があって
環境のセットアップが大変なんだそうな。


Google社なんだからクラウドリソースがたくさんあるわけで
クラウドを使おうよとなったらしい。

最初はGoogle社有名な20%時間内ではじめて、
Special Projectになって、
Chromeで使うようになったらしい。

コンパイラも都度送らないで
予めコンパイラは幾つか決め打ちで用意して
クラウド環境(Linux)にうかべ
同じコンパイルは再利用出来るようなキャッシュをつくって
ローカルにはcompiler-proxyを作って
makeの時にノード数を設定できるようにして
巨大ファイル送信は2MBごとにわけて
もちろんこの単位でキャッシュが効くようにして
とアーキテクチャは地味..^H^H堅実なかんじにできている。

コンパイラやると禿げると某氏が言っていたが
地味に針をチクチク入れていく感じの作業だったのだろうと
想像する。

MacOSのコンパイラは最初クロスコンパイラでやっていたが
WebKitのコンパイルは通るが動かない
なんてことがでてきた。

で考え方を変えてmaloaderなるMacOSシステムコールを
Linux側の口にマップするようにして対応したり、
HTTP通信失敗時の時を考え
ローカルでもコンパイルをやって
答えが帰ってこない場合はローカルのオブジェクトを
使うようにしたり
レース編みの針の入れ方を部妙に変えるみたいな
作業があったそうだ。


gomaは
外部公開することはなさそうだけど
Google社員が一見華やかそうに見えて
結構地味な作業をこつこつやっているんだな
ってことがよくわかった。


0 件のコメント:

o1-previewにナップサック問題を解かせてみた

Azure環境上にあるo1-previewを使って、以下のナップサック問題を解かせてみました。   ナップサック問題とは、ナップサックにものを入れるときどれを何個入れればいいかを計算する問題です。数学では数理最適化手法を使う際の例でよく出てきます。 Azure OpenAI Se...