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
2004/04/22
http://homepage3.nifty.com/mogami/diary/d0404.html#21t5
実は液晶というのは単位面積あたりのドット数を増やしても歩留まり （つまりコスト）が変わらないらしい。そういうことなら今すぐにでも ドット数を倍増させてなめらかな文字を表示できるようにするべきだと 思うのだがなぜどこのメーカもやらないのだろうか。 OSが対応しなければならないと言うのはあるのだけれど。
ドット数が4倍になると、ディスプレイへの転送バンド幅も4倍、 フレームバッファも4倍、GPUのフィルレートも4倍、 フォント等ベクトルデータのラスタライジングの計算量も4倍になる、 ってあたりがネックなような気がする。 フレームバッファの量は最近のGPUなら問題なさそうだけど。
映像信号までは既存のままで、LCD素子側でフィルタかけちゃうとか いう手はありかもしれないが、せっかくの解像度があんまり嬉しくないような。
3年くらい前に200dpi, 3800x2400くらいのLCDを展示会で見たが、 もの凄く綺麗だった。理想的には300dpi、30inchくらいのディスプレイで 作業したい。そしたら、机の上に紙を広げてる感じに近くなるんではないか。 解像度でいうとIMAXくらい? そう遠くない話だと思う。
あと、ダイナミックレンジもね。昨年のSIGGRAPHでhigh dinamic range なディスプレイが展示されてたけど、あれを見たら普通のディスプレイが くすんで見える。ただ、長時間見つめていて目にいいかどうかはわからんけど。
Tag: Hardware
2004/04/16
http://www.onweb.to/palestine/siryo/jo-fallujah-en.html (邦訳)
大義の無い戦争だろうと、始まってしまったらあとはどうやって 最小限の被害で終わらせるかを考えるしかない。その大前提は、 「共通の敵＝テロリスト&フセイン残党」という図式を保つことだった （それが正しいか否かは別の話）。 それを現地で恨み買うような真似してどうなるのさ。
「共通の敵＝米国」と認識されたら、もう手の出しようがないじゃん。 真実がどうであれ、「そう思わせない」ことが、最低限の戦略、 何をおいても守るべき一線だったんじゃないか。
米国はもう手を引くようにとの請願： http://www.moveon.org/unauthority/
すぐに国連が何もかもやるのは無理だろうし、拒否権に阻まれて 動きが取れないかもしれないが、 米国の戦略は下手すぎる。
Tag: 生活
2004/03/26
プログラミングと体力
ハッキングには体力が重要だ。ただし、ここで言う体力とは、 納期前に連続で徹夜できる体力のことではなく(それも重要ではあるが)、 抽象的なアイディアを具体的に動くものにまで持ってゆく力のことである。
効率的なフォームで走ることを思い浮かべることができても、 実際にそのフォームでフルマラソンを走るためには、 アイディアを実現するに耐える肉体が無ければならない。 美しい映像を思い浮かべることができても、 それをキャンバスに写し取るには、手が理念についてきてくれなければならない。 それらは、訓練と経験によって培われる、広い意味での基礎体力とでも 呼べるものだと思う。
分野を問わず、必要とされているのは、内なる理念と、表現するデバイスとを 繋げることだ。そして、基礎体力は両者を繋ぐチャネルのバンド幅である。 抽象的なアルゴリズムを、実際の現場のコンテキストで動作するプログラムへと 具体化する過程にも、似たようなチャネルがあるように思える。
プログラミングにおける基礎体力は、こんな形で現れる。 アイディアを思いついた時に、そのアイディアを核としてとりあえず 動くものをでっちあげてしまう。多くの場合、できあがったコードのうち、 アイディアそのものを具現している部分はほんの一部にすぎず、 残りの多くはそのアイディアを地面に固定させるための仮の骨組みや足場に すぎない。仮の骨組みや足場を作るのは、面白味のない単純作業だが、 それが無いと大事なアイディアを試すことが出来ない。 この時、そういう骨組みや足場をえいやっと素早く作ってしまえる能力が、 基礎体力だ。
重要なのは、そこにかかる時間である。そういう足場を作れるか作れないか で言えば、多少なりともプログラミングの心得のある人なら作れることが 多いだろう(結局のところ、そういう足場には新しいことは必要ないのだから)。 だが、そこで時間を喰っていると、肝心のアイディアがどんどん古びていってしまう。 アイディアはナマ物だから、捕まえたら十分に素早く料理しなければならない。 下拵えだの出汁を取るだののためだけに料理の本をひっくりかえして もたもたやってたら、アイディアは腐ってしまう。
この基礎体力の恐ろしさは、それが指数的に効いて来ることだ。
- まず単純に、アイディアを実装して試してみるのにA氏はB氏の半分の時間で済むと すると、A氏はB氏の2倍のアイディアを試してみることができる。 英語の学習には多読も有効だが、ペーパーバック1冊1日で読める人と、 1冊に10日かかる人とでは、学習としての多読の効率は10倍違って来るわけだ。 本人が注いでいる労力は少なくとも主観的には同じなのに。 さらに、経験すればするほど効率が良くなるとすれば、差はひらくばかりである。
- だがそれだけではない。頭の中と表現デバイスとのチャネルは 双方向なんである。Paul Grahamも アイディアは、より多くのアイディアを生む と書いているが、アイディアを形にしてみることではじめて 得られるアイディアというのが多数ある。従って、 速く形にすることが出来ればできるほど、 たくさんのアイディアが得られることになる。 たくさんのアイディアのストックを持っているということは、 実装の戦略を検討する際に選択の幅がひろがるということでもあるし、 行き詰まった時に道を開くためのヒントをたくさん持っているということでもある。 これら全てが、ものつくりを加速する方向に作用する。
この指数的なカーブのどこかに、クリティカルな基礎体力の閾値というのが あるような気がする。多少幅はあるにせよ、それ以下の体力の場合、 有用な結果が得られるまでにあまりに時間がかかるため、 本人の気力が萎えてしまったり、時間切れになるなどして、 結果が出せずに終わってしまうということだ。
いろんなものをつくり出す力、創造性のようなものは、人によって あったりなかったりすると思われているふしもあるが、 頭の中でアイディアを生み出す力に差が無かったとしても、 体力が閾値を越えているか否かで、出力にall or nothingの差が現れる。
プログラミングにおける生産性は人によって桁違いの差が出ると 言われることもあるが、それは、プログラミングが 肉体の物理的な限界というものにあまり左右されないために、 この指数的効果がそのまま観測されるからではなかろうか。
なかなか結果が出せないと焦るものである。 知識が足りないからだと本を買い込んで例題を解いてみたりとか 能力が無いと諦めたりとか。 だが、その理由が、基礎体力が閾値以下であるせいだとしたら、 基礎体力をつけること以外に逆転はあり得ない。 そして、基礎体力をつけるには、自分の頭の中の考えを 形にしてみる、という訓練を重ねるしかないのだ。 (既に閾値を越えている人が行き詰まって悩む場合はまた別で、 そこにはシリアスな問題が横たわっていたりするんだが、 どうも、体力不足の人も自分の問題をシリアスにとらえがちのような 気がする。)
(ここで 述べられている、日本と欧米のCSの大学院生の差なんかも、体力の差のような 気がする。話をしてみると日本の学生にもすごい人は多く、頭の切れという 点ではそれほど差はないと思うのだが、出てくるものの量では 差をつけられているのではないか。あくまで印象論だが。)
(ここで言っている体力は違うようでいて微妙に重なるようでもある、 「体力と知力」も おもしろい。)
Tag: Programming
Comments (2)