未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

ロードマップと研究開発

ムーアの法則というのはIT業界にいるものなら誰でも知っている言葉だが半導体集積のペースは当面落ちそうにない。しかし、先に指摘したように(Googleの電気代)、無分別にプロセッサの周波数をあげていくとその二乗に比例して消費電力が上がるので、消費電力あたりの性能は下がってしまう。（周波数が2倍になったとして、消費電力が4倍になる、性能が４倍になるというわけではなくよくて2倍弱なので消費電力あたりの性能は下がる。）そうすると単位面積あたり倍になったトランジスタを何に使うかという話になる。
結局、マルチコアあたりになる。集積度をあげ、スーパーパイプラインだ、スーパースカラだ、アウトオブオーダーだ、といろいろ知恵を絞ってプロセッサの性能向上を図ってきたが、これをさらに推し進めるには設計が複雑化しすぎた。というような事かと思う。じゃあ、まあ、とりあえづ、設計をそんなに複雑にしないで、ひとつのコアの上にほぼ同じ設計のものを2つあるいは4つ将来的には8つとか16個とか載せてしまいましょう。ということで結局、マルチコアあたりになる。周波数は同じで2個載せれば消費電力は倍になっても性能が倍近くになれば消費電力あたりの性能は悪化しない。むしろ微細化だなんだでマルチコアであれば消費電力が倍になることはないと期待できるので、ひょっとしたら消費電力あたりの性能は向上しちゃうかもしれない。結局、マルチコアあたりになる。
この手の話はムーアの法則が数年レベルで研究開発の方向性を決めるので、研究開発の羅針盤として非常に重要である。研究開発の方向性というか戦略というのは多額の投資を必要とするので急には方向転換できないため、コミュニティで同意されているロードマップというのがどうしても必要になる。ムーアの法則は、日進月歩、秒進分歩、ドッグイヤーとよばれているIT業界のロードマップとして40年以上も君臨してきた稀有の存在である。

それがソフトウェア開発にどうインパクトを与えるかという話である。

ムーアの法則のもと、メモリの単価は18ヶ月で半分になる、そうすると同じコストで3年後には4倍のメモリを搭載したサーバが登場する。製品を企画するものは、それを前提に商品を設計しないといけない。プログラマはメモリがどんどん増えるという環境のもとそれを前提にソフトウェアを設計実装しないといけない。
例えばコンパイラの実装を考えてみる。コンパイラの教科書を見ると、コンパイラというのはソースコードをマルチパス（ソースコードを読み込む作業をパスとよぶ）で読み、いろいろな解析をし最終的にはオブジェクトコードとよばれるものに変換するソフトウェアだというような解説が書いてある。実装は別にマルチパスにしなくてもいいのだけど、論理的なフェーズとして、字句を読み込みそれをトークンに分解して、構文解析木を生成し、最適化を施し、オブジェクトコードを出力するとき、何かと元のソースコードを参照したくなるので複数回ソースコードを読むというマルチパスの実装というのが一般的かと思う。大学でもそのように教わった。
DECに入ってCOBOLという古典的なコンパイラのチームに参加した。大学を卒業して最初の仕事が日本語COBOLコンパイラの開発である。そのCOBOLはしっかりとしたエンジニアリングのお手本みたいな実装になっていたのだが、新卒のエンジニアにはノウハウの塊のように見えた。その一つが、COBOLのコンパイラはマルチパスの実装になっているのだが、最初にソースコードを読み込んだとき、そのソースコードをすべてVAX/VMS上の仮想記憶に展開し、その後のパスでは実際の入出力は一切発生しないで仮想記憶上（メインメモリ）でやりとりをする。この実装が何がすぐれているかというと物理的な入出力が発生しないのでコンパイルの性能がでる。当時VAX 780という１MIPS言われているマシンで1分当たり約1000行程度コンパイルできた。最近のプロセッサは数千Bogo MIPSと言われているが、それに当てはめてみると数百万行を1分間でコンパイルできなければいけないが、残念ながらプロセッサの性能向上に昨今のコンパイラというかシステムは追いついているとは思えない。余談ついでに言うとこの1分1000行という性能目標はVAXのコンパイラチーム共通の目標で当時のFortranチームやAdaチームなんかも共有していた。Adaのコンパイル性能は世界記録だったと思う。NYUのサンプル実装が1分間に数行程度しかコンパイルできなかったのだから入出力時間の削減だけが高速コンパイルに寄与したわけではもちろんないけど。
それはともかくこの実装にも欠点がある。メモリが十分でないとページングが発生しかえって性能が劣化してしまうのである。しかしDECのコンパイラコミュニティは仮想記憶を利用するというアプローチをとった。なぜか。ムーアの法則である。ページングの発生はメモリが増加すれば減少する。VMSというOSは非常に賢くメモリを利用する。無駄なページングの発生はOSが解決すべき仕事でコンパイラの仕事ではない。メモリが増えればソフトウェアに一切の変更なく自動的に性能が向上するという仕組みを埋め込んでいるのである。
と言われてみればどうということもない話ではあるが、新卒のエンジニアにとっては、なるほどなあ、目から鱗とはこのことだと思った。
同じことがRDBMSの実装にも言える。メモリを大量消費するアーキテクチャに商用RDBMSはなっている。64ビットマシンに移行するだけで性能が飛躍的に向上するという仕組みになっているのである。性能が必要だったらメモリを積めという話である。
これも余談だが、わたしの見る限り、PostgreSQLもMySQLもその意味で64ビット環境に最適化されていない。（もし間違っていたら指摘してほしい）これからの課題といっていいだろう。
ムーアの法則のおかげでOSもRDBMSも長期的にはメモリを上手に利用するという方向で研究開発を推進してこれた。キャッシュがどうだという重箱の隅をつつくようなお話もムーアの法則の手のひらの上で踊っているということである。
集積度の向上がマルチコア化という方向へ向かうとすると、従来のマルチプロセッサ向け技術がますます重要になってくる。SMPをどう生かすかというのがソフトウェアでますます重要になってくるのだけれど、紙面が尽きたのでまたの機会に。

Mozilla Party JP 7.0

今年で7回目というMozilla Party JP 7.0に参加してきた。盛況であった。

もじら組セッション

甲府方さん
途中から参加なのでちゃんと聞いていない。すいません。

Mozilla Japan

瀧田さん、Mozilla Party JPは皆勤賞だそうだ。
Gen Kanaiさん、Mozillaのマーケティングのお話。日本でのマーケティング活動。

  • 2006年度、現状のマーケットシェア（現在3％）を10％程度にしたい。
  • japan.spreadfirefox.com
  • イベント/Interop Tokyo

今後の活動

アイデア募集中

Tシャツを着て街を練り歩こう〜

Firefox and the next-generation Mozilla platform

Darin Fusher (darin@google.com)

CD/USB Bootable OpenOffice.org

鎌滝雅久さん　OpenOffice.org 日本ユーザー会
USBから起動するOOoのお話。OSから起動するというのではなくて、あくまでOOoの起動。

ScrapBook の紹介と今後のプラン(Gomitaさん ScrapBook 開発者)

ネットワークにつながっていないのでデモの迫力がそがれていた感じではあるが、大変興味深い。拡張機能。

悪意ある拡張を作ってみた(下田洋志 aka Piro さん　株式会社グッデイ　オープンソース開発部)

危ない話。

二次会

いろいろ熱く語る。

Mozilla Party Jp

Mozilla.party.jpに参加だ。1998年3月31日に今はなき米国Netscape社はその主力製品Netscape Navigatorのソースコード（Mozillaとして知られる）を公開した。

自分にとっての衝撃はこの日記でも何度か記した。Mozillaの公開がわたしをオープンソースの世界に引きずりこんだといっても過言ではない。オープンソースというものがなかったらミラクル・リナックスという会社の設立にかかわることもなかっただろうし、そもそもミラクル・リナックスという会社もなかった。

オープンソースというものに出会い、そして会社の設立にいたるまでのきっかけを作ったのはMozillaのコードの公開である。人生踏み外したな、お前とか言われそうであるが、そのくらいMozillaの衝撃は大きかった。普通のサラリーマンにとって転職するとか、ましてや会社の設立にかかわるなんていうことはよっぽどイキオイがないとできない。できないのであるが、それを決断させるほどオープンソースには魅力があったのである。お前馬鹿だなと言われそうであるが、はじめてしまったのだからしょうがない。当事者として関わるというのはそのようなものだろう。誰かに言われてやるのではなく心の奥底からの叫びによって突き動かされる。衝動である。

というようなことを思いながらビールをぐびぐび飲んでいたのである。