2004/04/25

Lispで一番クリティカルな部分を速度で最適化する場合、 (optimize (speed 3) (safety 0)) とかにして、 型宣言をつけまくるわけだが、関数を編集して再定義したら インタラクティブに(disassemble 'foo) してどういう アセンブリコードが出てるかを調べる、というのをよくやる。 首尾良くCで書くのと同等のコードが出たらニンマリ。 もちろん(safety 0)だとミスればSEGVるところまでCと同等になるんだけど。

結局そのへんの泥臭さってのは、Cで書いててもLispで書いてても 似たようなもので、Lispプログラマも必要に応じて 「コードがどういうアセンブリに落ちるか」を意識する。 というか、80年代からLispやってた人達ってのは性能に関する議論を はじめるとだいたいそのレベルで考えるみたいで、 すぐに「こっちの方が1インストラクション少なくて済む」とか 「メモリロードが少なくなる」とかそういう話になる。 (MLerもコンパイル後のコードにセンシティブなような 印象があるんだけど、あんまり話したことないから知らない)。

そういう「低レベル(=アセンブラに近い)プログラミング」を している場合でも、Lispだとマクロを使ってがんがん定型処理を 自動化してくから、Cで書くのに比べてはるかに楽ではあるんだが。

このへんの感覚は、90年代以降に登場した高級言語とちょっと違う ような気がする。処理系そのものにタッチしている人を除いては、 その言語をかなり使ってる人でも、コンパイラの吐くコードがどうかって 考えながら書く人ってあんまりいなさそう。 それをしなくていいのが高級言語のいいところ、ってのはそうなんだけど、 クリティカルな部分でunder the hoodのどろどろしたところを いじりたいっていう要求もあるわけで。

効率は欲しいけどそういうどろどろは嫌、って人がstatically typedな 関数型言語に流れるんかな。コンパイラを賢くして全部やらせようっていう。

まあ、Lispっつっても処理系はいろいろあるわけで、 バイトコード処理系だとそこまでこだわりはないしな。 Gaucheだってネイティブコードにコンパイルしての最適化までやる気はないし。 VMレベルではもっと速くしたいけど。

いやまてよ。新しめの言語に比べて、そもそもLispは処理系に興味がある人くらいしか 触ってないって可能性があるか。

Tags: Programming, Lisp