あなたのHaskellプログラムを速くするのにあたって、鍵となる道具はGHCのプロファイル機能である。これは別途第5章. プロファイルを取るで説明されている。プログラムが時間/空間をどこで使っているのかについて実際のこと(あなたがどんな風に想像しているかではなくて)を知ることにおいて、プロファイルを取ることに代わるものは存在しない。
もう一つ銘記すべきことだが、プログラムの性能を劇的に向上させるための圧倒的に良い方法は、より良いアルゴリズムを使うことである。プロファイルによってどこが時間を食っているかが分かったら、下に書いてあるもろもろの調整を試みる前に、プログラムについて再考した方が良いだろう。
プログラムを速くするためのもう一つの極めて効率的な方法は、誰か別の人によって真剣に調整されたライブラリコードを使うことである。Data.List
にあるのよりも良いクイックソートを書くことはできるかもしれないが、それはimport Data.List
とタイプするのに比べてずっと大きな時間が掛かるだろう。
GHCでコンパイルされたプログラムが過度に遅いときは、どんなものであれ報告してほしい。近頃は速度に関してGHCにまともな競争相手がいなく、過度に遅いとはどういうことかはっきりしないので、自分の判断を使ってほしい。もちろん、GHCでコンパイルされたプログラムが、同じプログラムをNHCやHugsでコンパイルしたものよりも遅いなら、それは間違いなくバグである。
-O
または-O2
を使う)これはプログラムを速くするにあたって最も基本的な方法である。コンパイル時間は遅くなる。特に-O2
のときに顕著である。
現在、-O2
は-O
とほとんど区別が付かない。
LLVMコード生成器は、ネイティブコード生成器と比べてずっと良いコードを生成することがある。これは普遍的なものではなく、コードに依存する。激しく数値演算するコードは、LLVM経由でコンパイルしたときに最大の改善を見せるようである。また、-optlo
および-optlc
フラグを使って特定のフラグをLLVMに渡すのを実験してみることもできる。ただし、これらのフラグを設定するとGHCは通常のフラグをLLVM最適化器とコンパイラに渡さなくなるのに注意。
Haskellの(型クラスを使った)多重定義は洗練されているし、趣味が良いし、美点を挙げればきりがないが、これが内側のループに残ったままになると性能には致命的である。これをつぶすには次のような方法がある。
シグネチャを書くというのが基本的な技である。そもそも、エクスポートされた最上位の関数に型シグネチャを書くのはソフトウェア工学上の良い習慣である。(ヒント: -fwarn-missing-signatures
を使うと、シグネチャに関して良い習慣を保つのが楽になる)
エクスポートされていない、あるいは局所的に定義された多重定義関数については、自動特殊化(-O
で有効になる)が面倒を見てくれるはずである。
SPECIALIZE
プラグマを使うプログラム中で鍵となる関数について、多重定義を特殊化すると良い。7.16.8. SPECIALIZEプラグマおよび7.16.9. SPECIALIZE instanceプラグマ を見よ。
原始的な方法だが、インタフェースファイル上で多重定義された型シグネチャをgrep(検索)すると良い。インタフェースファイルは--show-iface
オプションで見ることができる。(4.7.7. インタフェースファイルに関連するその他のオプションを見よ)
% ghc --show-iface Foo.hi | egrep '^[a-z].*::.*=>'
であり、特に遅延パターン照合は敵である。
(「正格な関数」とは何かを知らないなら、関数型プログラミングの教科書を参照してほしい。ここで一言二言説明してもあまり役に立たないだろうから)
次のふたつの例を考える。
f (Wibble x y) = ... # 正格 f arg = let { (Wibble x y) = arg } in ... # lazy
前者の方が良いコードが生成される。
もう少し自然な例として、より正格なコード(目指すべきもの)のためにlet
の代わりにcase
を使うというのがある。
f (Wibble x y) # 美しいが、遅い = let (a1, b1, c1) = unpackFoo x (a2, b2, c2) = unpackFoo y in ... f (Wibble x y) # 醜いが、それで良い = case (unpackFoo x) of { (a1, b1, c1) -> case (unpackFoo y) of { (a2, b2, c2) -> ... }}
関数が、単一構築子の型(ただ一つのデータ構築子を持つ型のこと。例えば、タプルは単一構築子の型である)について正格ならなお良い。
データ型に構築子が一つしかなく、その構築子にフィールドが一つしかない場合、data
宣言ではなくnewtype
宣言を使うと良い。newtype
は大抵の場合最適化によって排除される。
推測しようとしてはいけない。問い合わせるのだ。
インタフェースファイル中でその関数を探し、そのプラグマ中の第三フィールドを探す。__S <strng>
となっているはずである。<string>
の部分がこの関数の引数の正確性を表している。L
はlazy(良くない)であり、S
とE
は正格(良い)であり、P
は「プリミティブ」(良い)である。U(...)
は正格かつアンパック可能(非常に良い)であり、A
は存在しないこと(非常に良い)を表す。
アンパック可能なU(...)
引数については、構成要素の正格性が括弧内に書かれる。つまり、もし引数が二要素のタプルで、U(AU(LSS))
と書かれていたなら、これが意味するのは「このタプルの第一要素は使われない。第二要素は再びアンパック可能で、三つの構成要素(第一要素についてはlazy、第二・第三要素については正格)から成っている」ということである。
関数がエクスポートされていないなら、-ddump-simpl
フラグを追加してコンパイルすれば良い。全ての定義について、型シグネチャの隣に、インタフェースファイルにあるのと全く同じプラグマ情報が表示される。(それから、コア表現は見ていて面白いですよ)
INLINE
化されるようにする(特にモナド)頻繁に使われるある種の関数に対してINLINE
プラグマを使うことで劇的な効果を期待できることがある。7.16.5.1. INLINEプラグマを見よ。
モジュールに明示的なエクスポートリストがないと、GHCはモジュール中の全てがエクスポートされていると考えざるを得ない。これは様々な悪影響を引き起こす。例えば、あるコードが実際には(もしかしたら展開の結果)使われていなくても、それはエクスポートされていて、他のモジュールに必要とされているかもしれないので、捨て去ることができない。
GHCは、エクスポートされていないと分かっているコードに対してはかなり攻撃的になることができる。
(コアとは、GHCがコードを操作する際に用いる形式のこと) -ddump-simpl
付きでコンパイルすれば良い。(-O
を付けるのを忘れないように)
プロファイルによってコストの高い関数が見付かったら、その関数のコア形式のコードを見てみると良い。let
は良くない。case
は良い。辞書(d.<Class>.<Unique>
)は良くない。入れ子になったラムダは良くない。明示的なデータ構築子は良い。プリミティブ演算(eqInt#
など)は良い。…
正格性注釈('!')を構築子フィールドに付けるのにはふたつの利点がある。第一に、プログラムがより正格になるので、正格性解析器のできる仕事が多くなる。第二に、スペースリークを減らすのに役立つことがある。
場合によっては三番目の利点もある。-funbox-strict-fields
(4.10.2. -f*
: プラットフォーム非依存のフラグ)が使われているとき、正格なフィールドは構築子中にアンパックあるいは非ボックス化され、一つまたは複数の間接参照の階層が取り除かれることがある。アンパックは単一構築子のデータ型にしか作用しない。(Int
が良い例である)
-O
なしに-funbox-strict-fields
を使うのはあまり良い考えではない。発生するパックとアンパックが最適化によって取り除かれないからである。実際、-O
を使っているときでさえ-funbox-strict-fields
が性能を悪化させることがあり得る。しかしこの可能性は低い。(もし起こったら知らせてほしい)
もし本気で速度を望むなら、そして「生の」部分を理解したいと思うなら、7.2.1. 非ボックス化型 に非ボックス化型の使いかたの情報がある。
明示的な非ボックス化型に訴える前に、正格な構築子フィールドと-funbox-strict-fields
を使う(上記参照)のを試した方がいいだろう。この方法なら、コードの可搬性を失わずに済む。
foreign import
(GHC拡張)を使って、速いライブラリとリンクするこれは大変だが、それでも、世の中には激しくチューンされたライブラリコードがたくさんあり、正しい道はそれらと競うのではなく、それらとリンクすることである。
第8章. 他言語関数インタフェース(FFI)に他言語関数インタフェースの説明がある。
Float
を使うなComplex
を使うなら、間違いなくComplex Double
を使うべきであり、Complex Float
を使うべきではない。(前者は大いに特殊化されているが、後者はそうでない)
Float
(おそらく32ビット)を使うのは、自分が何をしているか本当に分かっているのでない限り、大抵の場合悪い考えである。Double
を使うべきだ。速度上の欠点は滅多にない。現代の機械はどちらにも同じ浮動小数点数演算ユニットを使うからだ。Double
を使えば、数値的な誤差で自分の首を締める可能性がずいぶん少なくなる。
Float
を使うのが良案である場合の一つは、それが大量に必要な場合、例えばFloat
の巨大な配列である。これはDouble
の場合と比べて半分の領域しか必要としない。ただし、64ビットの機械ではこれは成り立たない。
UArray
)を使えGHCは、Int
やChar
などの基本的な算術要素型に対して、非ボックス化された値を要素に持つ配列をサポートしている。詳細はData.Array.Unboxed
ライブラリを見よ。これらの配列は、Data.Array
の標準Haskell98配列よりもずっと速いことが期待できる。
プログラムのGC統計情報(-S
RTSオプション)がプログラムが多くのGC(例えば実行時間の20%以上)をしていると報告する場合、より多くのメモリを使うことが有効かもしれない。これには、-M<size>
または-A<size>
RTSオプションを使う。(4.17.3. ガベッジコレクタを制御するためのRTSオプションを見よ)