2011/09/22

ドラマや漫画では、ある人物が素晴らしいアイディアとか解法を思いつく時ってのは、まるで雷に打たれるがごとくアイディアがどかんと降りてきて、彼はそれが正解であることを直ちに了解する。

もしかするとアルキメデス級の頭脳を持っていればそういうことが起きるのかもしれない。あいにく、自分の経験では、思いついたアイディアの正しさというのはもっとずっとゆっくりと、土に水が染み込むように認識されてゆく気がする。

「わかった、これだ、エウレカ！」っていう感じじゃなくて、「んー、じゃこう考えてみたらどうかな。んー、そうするとこっちはうまくいけるし、お、なんか全部いけたりして? いやまてよこっちはどうかな、あ、これはこれでいいんだ。え、ほんとにいけちゃうの? これ、ほんと? うわーいけそうだよ。うわー。」って感じ。で、じわじわと顔がほころんでくる。

ここ数日間、「時々性能が低下する」という厄介な問題を処理していて、とりあえず寝る前に報告だけあげとくか、とグラフ書いて手がかりになりそうなobservationを説明しているうちに、バグがわかってしまった。いや、本当にそれが正解かは今流してるベンチマークの結果を見ないとならないんで夜が明けないと確かなことは言えないんだけど、ロジカルには綺麗に説明がつくんでまあこれが正解かなと踏んでる。さっきまで眠くて眠くてとても情けない気分だったのに、今は嬉しくて仕方がない。

Tag: Programming

Comments (3)

2011/09/17

#permalink

新しいグリーンカード届いた (かみさんのはまだだけど)。おお、今度のは名前に違わずグリーンだ。前のより薄い感じがしたけど比べてみたらほぼ同じだった。ちょっと柔らかくて軽いのでそういう印象を受けたのかな。

Tag: 生活

Comments (0)

2011/09/15

#permalink

ピアノレッスン14回目

基礎。スケールとアルペジオは、2〜3日前からMM=144まで上げてみているのだけれど、多分マージンぎりぎりのところで弾いてて余裕がないためだろう、レッスン室のピアノだと全然だめだった。やっぱり指の運動機能よりは頭(制御部分)が律速になっている感じがする。正しい手と指の位置を明確にイメージする時間が間に合ってない。
Ravel: Sonatine。1〜3楽章ゆっくり。細かい点について色々注意やサジェスチョンを受ける。3楽章はMM=82で弾いたけど、これから速くしていきましょうと。楽譜はMM=144って書いてあるんだよなあ。恐ろしい。
そろそろ平行してさらう曲を選んどいてってことなので、ぼちぼちアルカンに挑戦してみることにする。昔さらったけどどうにも届かなかったOp39-2。まあ自分の限界がわかったらわかったで、また何年か後に再挑戦すればいいし。

Tag: Piano

Comments (0)

2011/09/11

#permalink

怒涛の1週間/劇評

先週の日曜と今週の金・土曜の "Mai Poina" walking tourが終わり、 "Cane Fields Burning" の初週の公演(木〜日)も終了。もうリハーサルは無いのでちょっと一息つける。たまっている仕事を片付けないと。

体調管理には気をつけてたにもかかわらず風邪をひいてしまい、喉にきた。風邪で腫れてるのは声帯よりも上なんで声そのものに直接の影響はあんまりないのだけれど、痰がからむので咳が出そうになることがある。オフの間に直さないと。

"Cane Fields Burning" の劇評をみつけた：Cycles of Violence Noh Beauty Can Tame — CANE FIELDS BURNING at KKT (写真に写ってる面は仮のもので、本番では別のを使ってる)

観客の出足はまだ少なめなので、ホノルル近辺の方、いらしてくださいな。チケットはオンラインで買えます。

(追記2011/09/13 11:18:34 UTC): 劇評もうひとつ。Honolulu StarAdvertiser誌。Review: ‘Cane Fields Burning’ at Kumu Kahua

Tag: 芝居

Comments (0)

2011/09/09

#permalink

言語レベルのスレッド

(続)Haskell(GHC)での軽量ユーザスレッドの実装方法 - あどけない話

ユーザスレッドの実装は、外部言語の関数呼び出しをサポートする際に行き詰まることが多い。つまり、呼び出した外部言語の関数でブロックされ、他のユーザスレッドが動かなくなる。
Haskell では、外部言語の関数呼び出し専用のカーネルスレッドを用意していて、ユーザスレッドがブロックされないようになっている。この手法は素晴らしいが、他の言語コミュニティは、素晴らしさに気付いていないようだ。

Scheme界では、確かBiglooが似たようなことをやってたと思う。Schemeレベルのスレッドはユーザレベルの軽量スレッドで、ブロックする可能性のある操作をカーネルスレッドに依頼するという。もうずいぶん前に聞いた話だから定かではないけれど。確かFairThreadsモデルの上に構築されてたって話だった。

FairThreads: mixing cooperative and preemptive threads in C (pdf)

この論文はCだし、Javaの実装もあるからScheme界限定ってわけじゃないのか。

Gaucheでスレッドをどう見せるべきかってところは結構悩んだんだけれど、言語レベルスレッドのサポートが欲しい2大理由が

ブロッキングI/Oを気にせず書きたい
マルチコアを使い切りたい

だったのと、ユーザレベルスレッドはSchemeなら欲しけりゃ簡単に書けるってのもあって、カーネルレベルスレッドを直接見せることを選んだのだった。

また、ベストなスレッドモデルがわからないうちに言語レベルスレッドモデルを決めてしまうのが早過ぎる最適化になるということも恐れた。カーネルスレッドを直接見せておけば、色々なスレッドモデルをその上に作って試してみることができる。

で、まあ最近の考えとしては、やっぱりカーネルスレッドを直に使うのは面倒だなあってとこに行きつつある。とはいえ完全に隠してしまうと、ネイティブスレッドの使い方をプログラマが管理したい場合に困る。

アプリケーションを書く時とライブラリを書く時で欲しいスレッドの抽象レベルが違うってのが問題なんかな。アプリケーションを書く段階になると、コアがこれだけあったらネイティブスレッドをこういうふうに割り当てて、という勘定をきっちりしたい時がある (気にしないでいい場合も多いけど、気にする必要がある時もあるってこと)。一方、ライブラリを書く場合は、どういうアプリケーションが使うかまだわからないから、なるべく抽象度の高いスレッドモデルに乗っかっておきたい。

今、futureの実装をどうするか考え始めてるんで、ぼちぼちこのへん決めないとならないんだけれど、どうするかなあ。

Tags: Programming, Gauche

Comments (0)

More entries ...