研究室のリストに流したのでここにもついでに書いておく。 djb が2015年にやった「最適化コンパイラは死んだ」という講演の抄訳。
Death of Optimizing Compiler
Daniel J. Bernstein
- スライド: http://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf
- 音声: http://cr.yp.to/talks/2015.04.16/audio.ogg
…この講演のタイトルは「最適化コンパイラの死」ですが、 皆さんの中に「最適化コンパイラ」が何か知っている人はどれくらいいますか? …ほとんどですね。では「死」については? (笑) …そんなにいないようですね。 この葬儀に大勢の人々が参加してくれて嬉しく思います。
私がプログラミングを始めたのは 80年代前半ですが、このころ IBM PCの クロック周波数は 4.77MHz でした。いま私のノートパソコンは数GHzです。 昔はアセンブラでプログラムを書いていたものですが、今はみんな Pythonかなにかで書いています。いまやプログラマが速度を気にする必要は なくなりました。Knuthの「未熟な最適化は諸悪の根源である」という 文句は誰でも知っていると思いますが、これは今でも成り立ちます。 なぜなら最適化コンパイラが間違えることもあるからです。しかし もはや速度は誰も気にしなくなったので、最適化コンパイラは その役割を終えました。以上。
…まだ時間が残っているようですので (笑)、追加のスライドを 用意してあります。実際には、上の話はいささか単純すぎます。 まだ多くの人がコンピュータは時間がかかると思っているわけですね。 たとえばCGなどで完璧な物理シミュレーションをしたいとすると、 現在のコンピュータでは時間がかかりすぎます。 昔むかし、CPUがファイルを開いて画像を読み込んで表示するまでには 時間がかかったので、人々はファイル操作を速くするために 多くの労力をつぎこみました。今ではこの部分は一瞬で終わりますが、 人々はもっと大きな画像を処理しようとします。すると最適化する対象が 昔と比べて異なっているわけです。
いまでは「平坦なプロファイル」という考え方は過去のものに なっています。コンピュータのプログラムは巨大ですが、そのほとんどは 周縁的な処理であって、本当に最適化が必要な部分の比率は減っています。 この部分こそ我々が本当に性能を気にする「ホットスポット」ですが、 この部分はますます局所的に、そしてますます「ホットに」なっているのです。
例として、HTTPSに使われる暗号化があります。 最近CloudFlareが暗号化アルゴリズムを切り替えましたが、こうすることで スマートフォン上の電力消費をかなり節約できることがわかりました。 面白いのはサーバ側の話で、彼らはIntelのアセンブリで書かれた サーバ側の暗号化コードを手で最適化したというんです。実際には Perlスクリプトがアセンブリを生成するんですが、ここでは 最新のIntelチップに入っている"vp〜"命令を多用しています。 最適化コンパイラは使っていません。21世紀にもなって、彼らは 一体何をしているのか?
たとえばWikipediaにはこう書いてあります: 「1990年後半までに、最適化コンパイラの吐くコードは 人間が手で最適化したものよりも速くなった。」 こういうのを見るといつも「要出典」て書きたくなりますよね。 Wikipediaは私が知っている以外のことについては全部正しいんですが (笑)。 現実にはこれと反する事ばかり起きています。たとえば最適化コンパイラが 凡庸な計算ライブラリを OpenBLAS (世界記録保持) と同じくらい速くする ことができるでしょうか? そういう話は聞いたことがありません。
ここで、アルゴリズム開発者の立場を考えてみましょう。現在のほとんどの アルゴリズム開発は、たいていわずかな時間を改善するために行われています。 このような場合、計算機のアーキテクチャをかなり精密に 定義しておかねばなりません。レジスタのサイズから並列化の方法から キャッシュの方式まで。教科書的な単純なRAMのモデルではだめなのです。 また、ほとんどのアルゴリズム研究の成果は非常に特定の分野に 特化されています。その分野の特性をよく学習してからでないと効率のよい アルゴリズムは作れません。では最適化コンパイラは アルゴリズム開発者と同じことをやっているのでしょうか?
最適化コンパイラの研究者は、彼らの仕事はマシン非依存の コードをとってきて、それを特定のマシン用にちゃんと最適化することだ といいますが、実際にはカリカリにチューニングしたアルゴリズムを 実装するためには対象のマシンの特性をフル活用する必要があるのです。 この点で、アルゴリズム開発者にとってコンパイラの存在はかえって邪魔です。 もちろん、それほど速度が重要でない部分でマシン非依存のコードを 書ければ全体の時間は節約になりますが、そもそも速度が重要でない部分であれば 最適化の必要はありませんよね? また、現在のCPUアーキテクチャは昔と比べて よりバリエーションが少なくなっており、マシン非依存のメリットは 相対的に減っています。
私が思うに、現在のコードは二極化してきているのです。つまり、非常に 頻繁に実行され、手でカリカリにチューニングすべき部分と、ほとんどまれにしか 実行されず、したがって最適化も必要ない部分。コンパイラの最適化は バグの元にもなりますから、必要のない部分まで最適化するのはよくありません。 私の意見では、最適化コンパイラの研究は、アルゴリズム開発者が その分野の知見を活かして、そのマシンの特性をよりうまく使えるように 支援する方向に向かうべきだと思っています。
(ここで、いかに現代のCPUアーキテクチャを 特定の計算分野に適用できるかという話は省略)
…Python のようなインタプリタだけの言語で仕事をするというのは 30年前では考えられませんでしたが、今では普通です。 今はまだ過渡的な段階ですが、コンパイラも同じようにほとんどの 部分は最適化せず、最適化するのはごく一部だけでそれも手動、 という流れになっていくと思います。こんにち我々が知っている 「最適化コンパイラ」は過去のものになるでしょう。
omg its already aughust
I like tomatoes, and so does everyone. It's one of my favorite fruits/vegetables... thingies. But when you think about it, I found it's actually a pretty gross fruit in its aesthetics. Its color is red, and there's a dark green goo in it... ugh
英語を日常的に話し始めて10数年。 新山がいまだに練習(!)しているのが、L と R の正しい発音である。 なぜかっつううと、日本語を話しているとだんだん L と R が影響されてくるからで…。 落ちついていれば使い分け (発音し分け) はできるのだが、問題はとっさの一言である。 とくに母音なしの L とか R だけ ("al", "ore" など) を単体で発音するのがむずかしい。 なぜかっつうと、たいていの日本人と同様、新山もまた多くの子音を母音と 結びつけて覚えがちだからである。だから "la" とか "ra" は 比較的できるのだが、単体で "l" "r" だけを発音するとコケやすい。 で、日本語の「ラ」行は L と R の中間であるとよくいわれるが、 最近いろいろ考えていたら、どうやら日本語の「ラ」は "lra" という表記が 正しいんではないかと思いだした。そんだけ。(オチなし)