Google Open Source Blog

コンパイラ関連の技術や実装としてはLLVMが活躍の場を広げている。先日もAdobe LabsにおいてLLVMを活用したプロジェクトAdobe Alchemyが発表されたばかりだ。AlchemyではC/C++ライブラリをFlash Playerで実行することを目指しており、LLVMの仕組みが目的によく合っている。後発のプロジェクトだけありLLVMはインフラストラクチャとしての見通しがよく、C/C++コンパイラとしての側面だけでなく汎用的なビルドおよび実行インフラストラクチャとして重宝されることが多い。

OSSのC/C++コンパイラとしてはGCCが代表的な位置づけにあるが、GCCもだまっているわけではないようだ。Google Open Source BlogにおいてWHOPR - A scalable whole program optimizer for GCCというGCCのコンパイル時最適化処理改善のための取り組みが紹介されている。

古典的なコンパイル、いわゆるmake -jで並列処理可能なC/C++コンパイルは、基本的に1ファイルごとにビルドをおこない最後にリンカがコンパイル後のデータを結合するという流れをとる。このため関係のないファイルは並列にビルドでき、マルチコア時代の現在と相性がいい。ただしこの方法はビルドの並列性は高いものの最適化という面では欠点がある。

単純な発想では、最適化率を引き上げるならすべてのファイルを結合してからコンパイルすればいい。この方法ならインライン化などを効果的に実現できる。実際のところコンパイラではベースとなるソースコードを直接結合するのではなく、リンク時最適化(LTO)という方法を使ってファイルにまたがる最適化処理を実施している。一旦ファイルを中間形式にビルドして、最後にメモリに読み込んで最適化処理を施すといった方法だ。

WHOPRの処理の流れ図 - WHOPR - A scalable whole program optimizer for GCCより抜粋

この方法は古典的な最適化手法のひとつだが、メモリを大量に消費するという問題も抱えている。Googleは大規模アプリケーションの開発も実施しているため、この最適化方法ではスケーラビリティに欠けるというわけだ。そこでGoogleではLTOを改善する方法としてWHOPR (WHOle Program optimizeR)を提案している。基本的な流れはLTOに似ているが、途中で最適化に適用できるサマリ情報を生成して別途保持するようにする。最適化のときに使うデータが保持されているため、あとは最適化処理を分散して実施することが可能というわけだ。大規模アプリケーションに対しても適用しやすいうえ、マルチコアで並列ビルドや複数のPCに分散させたビルドもおこないやすい。

WHOPRの実装はまだ初期段階にあるようだが、開発はすでにGCCのLTOブランチにおいて実施されており最初のプロトタイプ版は2009年夏に公開される見通しだ。GCCがOSSでもっとも活用されているC/C++コンパイラであることは間違いない。今後の発展に注目しておきたい。