第9回 測定狂時代まつもとゆきひろのハッカーズライフ(1/2 ページ)

ハッカーの多くは何らかのスピード狂的側面を持っているようです。しかし、最適化を始める前には、その作業が無駄になるかならないかを見極める必要があります。

» 2007年11月28日 07時40分 公開
[Yukihiro “Matz” Matsumoto,ITmedia]

測定狂

 「バカは風邪をひかない」といいますが、わたしのバカさ加減は幸い許容範囲内のようで、年に数回風邪をひきます。もっとも例年夏風邪をひくことが多いので「やっぱりバカなんだ」と思うことも多いのですが、今年はなんとか大丈夫だったようです。

 風邪をひくと体温計で体温を測ります。昔は水銀の入ったものでしたが、最近はデジタル体温計が主流のようです。測定が終わるとビープ音が鳴ったりして、なかなか賢いヤツです。さらに、わずか1秒で体温が分かる、耳で測定する体温計もあります。ガジェット好きとしてはぜひ欲しいアイテムですが、家族の理解が得られず、まだ入手していません。

 風邪をひいたときの行動は人によっていろいろでしょうが、わたしはとにかく頻繁に体温を測ります。ひどいときなど数分おきに測定して、家族をあきれさせることもあります。でも、体温を測るとなんだか自分の体のベンチマークを取っているようで楽しくなりませんか? 病気が治っていく様子がうかがえるようで、病気でしんどいときの数少ない楽しみです。

 日常生活における測定といえば、体重測定があります。体温ほど熱心に測定する気にならないのは、なかなか自分の望む方向に(わたしの場合は減る方向に)変化しないせいに違いありません。健康のためにはもうちょっとやせた方がいいんだけどなあ。運動もしないでコンピュータの前に座ってばかりなので、増加していないだけでも喜ぶべきなのかもしれませんが。気乗りしないといっても、数日に1回は入浴前に体重計に乗り、その結果をPDAに記録してグラフを書いていたりするんで、やっぱり測定好きなんですね。

スピード狂

 さて、知人のハッカーの中には何人か「スピード狂」がいます。スピード狂といっても峠で自動車レースをするわけではなくて、プログラムの実効速度を速くするために異常に熱意を燃やす人たちのことです。彼らはRubyのようなスクリプト言語は使いません。「だって遅いじゃん」。使うのはもっぱらCです。まれにC++を使う人もいますが、あまり多くはありません。「C++は(コンストラクタとか暗黙の呼び出しがあるから)実行コストが直接的に見えないので好きでない」という人が多いようです。Javaは以前に比べてずいぶん高速化されましたが、それでもまだ不満そうです。また、個人的な知人たちの中にはいませんが、高速化のためにはアセンブラを駆使する人も存在すると聞いたことがあります。最もRISC以降、単にアセンブラで書くよりCなどで書いた方が高速化されることも多いようで、アセンブラ派はめっきり数が少なくなったようです。

 もちろん、そんな極端な人はたくさんいないでしょうが、ハッカーの多くは何らかのスピード狂的側面を持っているようで、同じ動作となるプログラムの実行時間を短縮するという課題は燃えるものがあります。プログラムを繰り返し実行しながら「ここをいじるとコンマ何秒短縮された」などとハックを繰り返すのは、ハッカーにとってある意味大変幸福な時間です。パズルを解くときの知的チャレンジに似ているからでしょう。

 CでコンパイルしたプログラムをCPUで直接実行するのに比べると、Rubyのようなインタープリタ型言語の実行はだいたい100〜1000倍くらい遅い*ことが知られています。では、スピード狂はまったくインタープリタ型言語に寄りつかないかというと、そうでもないようです。もともとの実行時間が長いほど、改善による時間短縮幅が大きく、より達成感を感じられるからです。インタープリタ型言語の場合、処理をどれだけライブラリルーチンで消費できるかが鍵になります。Rubyの各ライブラリルーチンはそれなりに工夫して作られていますから、上手に使いこなせば、素朴にCで実装したプログラムと同等に近い性能が出る場合もあるそうです。

無駄な努力

 プログラムの高速化のように、プログラムの意味を変えずに性質(実効速度やメモリ消費量など)を改善することを最適化*と呼びます。ハッカーは最適化が大好きですが、そのような最適化の努力がいつも報われるとは限りません。過去のruby-talkメーリングリストに以下のようなポスト(ruby-talk:158426)がありました。

 わたしの会社ではC++による3次元レンダリングソフトを利用しています。そのソフトはJavaScriptとLua*のバインディングを提供していました。LuaはRubyほど使い勝手が良くなかった上、速度とメモリの効率化のため、より面倒なプログラミングテクニックを使う必要がありました。そのテクニックは確かに効果があり、FPS*は1〜2%向上していました。わたしは大変苦労してLuaのプログラムを書き、単純なシーンのレンダリングで890〜910FPSを達成したことに誇りを覚えていました。

 しかし、昨日、C++プログラマーの1人がレンダリングアルゴリズムにある変更を行ったところ、FPSが劇的に向上しました。いままで15FPSだった複雑なシーンのレンダリングが170FPSでできるようになったのです。われわれが非常に苦労して実現した数%の向上など、10分ほどかけて適切なアルゴリズムに変更するだけで吹き飛んでしまったのです。


 ソフトウェア業界には、昔から「premature optimization is source of all evil(早すぎる最適化はすべての悪の源)」という諺があります。プログラムの高速化においては努力がいつも報われるとは限りません。むやみな高速化の試みは、かえってプログラムの見通しが悪くなったりする弊害の方が大きいのです。

このページで出てきた専門用語

100〜1000倍くらい遅い

とはいっても、実際には実行時間のほとんどがCで書かれたライブラリルーチンの中で消費されるので、直接1000倍の差がつくことはめったにない。

最適化

最適化とはいうものの、最適(最も良い状態)になることはめったにない。より正確には「ちょっとマシ化」とでも呼んだ方が良さそうだ。英語では「optimization」と呼ぶ。「optim-」は「optimistic(楽観的)」からきているから、英語の方が実態を的確に表現しているようだ。

Lua

ブラジルで開発されたスクリプト言語。アプリケーションの組み込みの容易さと実行速度速度の高速高速さが特徴だといわれている。ブロックが「end」で終わるところだけはRubyに似ているかも。

FPS

Frame Per Second。1秒間に処理できる画面数。


       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ