夜まで続くHaskell談義

Yu SUGAWARA @gusmachine

気になったので @tanakh 召喚 RT: @jmuk http://togetter.com/li/122555 華麗にスルーされているが、最近のGHCのコンパイルってC/C++なみに速いのか？　テンプレバリバリなC++よりはましなレベルという認識のままだったんだが。

Hideyuki Tanaka @tanakh

@gusmachine nativecode-gen だったら、C++よりはだいたい速いと思います。

Yu SUGAWARA @gusmachine

nativecodegenのドキュメントを探したら2002年のものが出てきた。そんな前からhaskellしてないぞ.. http://bit.ly/i3TptK

shelarcy（しぇらーしぃ） @shelarcy

@gusmachine プログラムをコンパイルする時にデフォルトで使用されるのが、NCG（native code generator）ですね。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @gusmachine ええと、それはちょっと誤解のある書き方ですね。 @jumk さんが GHC を使ってた頃は最適化オプションを使うと C 経由でコンパイルされていましたが、現在は最適化オプション使用時もデフォルトで NCG が使われるようになってます。

Yu SUGAWARA @gusmachine

@shelarcy @tanakh @jumk なるほど。だからさっきの古いドキュメントに second-class citizen とあるのですね。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @gusmachine で、デフォルトの NCG を使っていれば、コンパイル速度は速いという話ですね（逆に C 経由でコンパイルするための -fvia-C オプションは、GHC 7.2.1 で基本的には無効化される予定です http://j.mp/fYCqIr ）

shelarcy（しぇらーしぃ） @shelarcy

@gusmachine @tanakh @jumk そうですね。現在では逆に C 経由でのコンパイルが、second-class citizen になりましたが。（今後は NCG が対応していない環境（Unregistered Build）で、処理系を動かす場合のみ利用できます）

Hideyuki Tanaka @tanakh

現状でも-fvia-Cのほうが速くなることが多いように思うのだけど、どうして使えなくするのだろう？

shelarcy（しぇらーしぃ） @shelarcy

@gusmachine @tanakh @jumk あと、本当に古いドキュメントだと、当時は GHC の NCG を実装し始めた実験的な段階だったというのもあると思います。（そこまで古くから GHC を利用していなかったので、当時のことは想像するしかないですが。）

shelarcy（しぇらーしぃ） @shelarcy

@tanakh NCG の生成するコードの品質がそれなりのレベルに上がってきた（まだまだ問題がありますが）のと、C 経由でのコンパイルを諦めれば使えるレジスタの数が増えて NCG の生成するコードの品質が上げられる [http://j.mp/hk2Lvp ] のと、

shelarcy（しぇらーしぃ） @shelarcy

@tanakh LLVM バックエンドが入ってきて、C 経由でのコンパイルのために Perl（Evil Mangler）をメンテナンスするのが割りに合わなくなってきたのが -fvia-C を止めたい理由ですね。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh というか、最近はコードを速くしたければ -fvia-C ではなく -fllvm を指定して LLVM バックエンドを使えって話になっていたと思います。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh あと、7.0.x 以降で NCG の生成するコードの品質に問題を感じる場合、x86 の浮動少数点演算に不満を感じるなら -msse2 オプションで SSE2 を利用するようにしたり [http://j.mp/hGjyvh ] 、

Hideyuki Tanaka @tanakh

@shelarcy なるほど。LLVMバックエンドの性能はそんなに良くなってるのですか。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh レジスタ割り当てに不満を感じるなら -fregs-iterative オプションを使って iterative coalescing やらせるようにしようよという話もありますね。 http://j.mp/1PTSG0 http://j.mp/bmxwuR

Hideyuki Tanaka @tanakh

-fllvmはなんかエラーが出て動かないなあ…。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh 全体としてどうかは分かりませんが、少なくとも GHC が現在あまり得意でないループ（再帰）処理の最適化に効きますね。 （repa が3倍速くなるという話があったように。 http://twitter.com/donsbot/status/26009428966 ）

shelarcy（しぇらーしぃ） @shelarcy

@tanakh LLVM 2.9 ですか？ 残念ながら LLVM 2.9 での変更にまだ対応できてません。（GHC 7.2.1 のリリースまでには直す予定だそうです。） http://hackage.haskell.org/trac/ghc/ticket/5103

Hideyuki Tanaka @tanakh

@shelarcy はい。2.9です。なるほど。対応できてないのですね…。

shelarcy（しぇらーしぃ） @shelarcy

あと、togetter に追加されることを期待してこれを再度書いておきますか。 http://twitter.com/shelarcy/status/26531819538

shelarcy（しぇらーしぃ） @shelarcy

[再掲] 遅延評価で高階関数が使えれば合成性のある I/O 処理を提供できるので、imperative な言語より表現力が高いというのが "Imperative functional programming" での主張です。 http://j.mp/2YWPHy

Hideyuki Tanaka @tanakh

llvmもGHCは対応版を同梱すべきなんじゃないのかなあ…？

shelarcy（しぇらーしぃ） @shelarcy

@tanakh Windows 版バイナリは対応版を同梱しても良いと思いますね。他の OS でやったら（主にインストールするバイナリサイズを気にする方から）怒られそうですが。

お惣菜 @n7k7

vectorは多次元配列じゃないじゃん．多次元配列が標準ライブラリに入ってるのはHaskell最大の美徳の一つ．