トップ 最新 追記

uDiary

海野秀之(うんのひでゆき)の外部記憶

Twitter (twilog) / RSS / アンテナ / ぶくま

2006|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|08|
2010|01|02|03|05|06|07|10|11|
2011|03|08|
2012|02|04|07|08|10|
2013|01|02|03|05|06|08|11|12|
2014|01|02|05|06|07|08|09|12|
2015|01|02|03|04|

2006-09-02 (Sat)

「あけてくれ」のライブに行きたい!

もう6年も前の記事ですが、 おれカネゴンさんところにあったの を読んで、不覚にもとても興味が沸いてしまった。 聞きに行きたい。

さっそく、ライブ情報を得るべく あけてくれ公式サイトへ。 うーん。あんまり更新されていないような感じがするのは、 気のせいだろうか。

「あけてくれ」はバンドです。ニュートラルは呑み屋です。

おお、ニュートラル情報がっ!

……

きゃあぁ。 もう無いの?

残念。くちでいうばっかりになってた、 yk氏と久々に飲む会をここで!とか思っていたのに。

っていうか、ハービーハン国て。


2006-09-05 (Tue)

でたー!(田崎さんの、新しい統計力学の教科書の草稿が)

某所に 「今、統計力学の本を書いてるからみんな読んでね」と 書いてあった のを見かけてから、その出現を見逃すまいと思っていたのですが、 ついに草稿が!!

http://www.gakushuin.ac.jp/~881791/statbook/

・2006/9/5

ボルツマンの百回目の命日に、7章までの未完成のバージョンを公開。

まだはじめの方を読んでみただけですが、面白い!!

「読み物」のように読んでも十分過ぎるほど面白いというのが、 実は、読者にとって最大の罠なのかも知れない。

大規模開発

ソフトウエアの開発手法のいくつかは、 ハードウエア開発における手法をお手本にしているといわれることがある。 たしかに、モジュール化などは、 ハードウエア開発においてはより厳密に実現されてきた。 おとなりのモジュールの中身をこっそり用いるなどということは、 それこそ、物理的に不可能だ。

ちょっと強引だが、つまり、大規模開発に関しては、 ハードウエア開発者の方に一日の長があるといえる。

……という話を念頭に、 Matz にっきのコメント (2006-08-26) を鑑賞していただきたい。

_ 咳 (2006-09-05 08:21)

大規模開発ってLOCとか機能の量とかそういうのじゃなくて、 メンバーの仲が悪い開発を言うんじゃないかなあ。

_ まつもと (2006-09-05 10:16)

座布団一枚。

座布団二枚。

お、シャノンのエントロピー

符号語の出現確率を用いて情報を圧縮するというのは、 つまり、こういうことである。

   少年:「今日タイガース勝った?」
 おやじ:「…」(無言)
   少年:「…」(今日も負けたんだな)

近頃のタイガースのようにちょくちょく勝つようになってしまうと、 このエンコード法はもはやベストの方法ではないのかも知れません。

ともかく、シャノンのエントロピーが統計力学につながっている とは、恥ずかしながら *1 知りませんでした。 (式の形が似ているだけだと思っていた)

*1 いまさらこの程度のことを恥ずかしがっていられませんが


2006-09-06 (Wed)

急に休暇

上に表示している 訪問者数カウンタ(ページビューを数えているわけではない)が、 ちょっと珍しい感じの数になっていたので保存↓

counter666.png

都合により、今日は急だが休暇に。 昼ごろバイオリンの練習をし、 市役所に寄り、その後県立図書館に出かけた。

[Violin] スケール練習(あとでちゃんと書く、かも)

バイオリンの練習は、スケール練習を主に行っている。 素直にテキストどおりに練習しているので、 テキストに書かれている練習フレーズもやるが、 今一番大切なのはスケール練習だと思う。

先週のレッスンで先生に言われたことや、 普段練習していて感じていたことを自分なりに反省していて 思ったことなのだが、 スケール練習も目的に応じていくつかのバージョンにわけて 行う方が効果的だと思う。

  1. ただしい音程を出して、それを耳・指で覚えるための練習
  2. 運指(?)をすばやく正確に行うための練習
  3. ただしい音程を自分で出すための練習
  4. 読譜のためのスケール練習

いままでは、上記のはじめの2つを、それとはあまり意識せずに (とくに、1と3の違いに無頓着なまま) 行っていたように思う。

まずは、かならずチューナーをみながら音を出す練習。 チューナーが「正解」と示す音程を出して、 そのときの音と指の形を覚える。

つぎに、スムーズな指の動きを身につけるためのスケール練習。 このときは、手・指の動作に集中したいので、 あまりチューナーばかり睨んでいられない。

いままでは、これら二つを意識しつつ練習していて、 それなりに効果はあったと思うのだけど、 ここ何回かのレッスンで先生にいわれたことが気にかかっていた。

いわく、音を出し始めた瞬間に、それを耳で聞いて、 すばやく正しい音程に「微調整」すると上手に聞こえる。

しかし、自分の出している音がちょっと高いのか、低いのか、 いまの僕にはぜんぜんわからない。 また、いまの練習方法でそれが獲得できるような気もしない。 つまり、耳を鍛えるための練習が不足している、というわけ。

あーねむ。 あとでもうちょっとちゃんと書くかも。

メモついで。 左手の手首が折れているために、左手の自由が利かないんじゃ ないですか?ともいわれた。 音程が調整できないのはそのせいではないんだけど、 左手が不自由なのは事実。 左手の手首も要注意だが、そもそもバイオリンをちゃんと 持てていない疑惑。肩当てを調整して、ちょっとマシになったか。

その他

「ヤバい経済学」を買ってきた。

ちょっと気になっていた「涼宮ハルヒの憂鬱」を借りてきた。 アニメ≒小説 >> コミック という噂を聞いていたので、 間違えないようDVDを蔦屋で。

「ハンカチ王子」に対抗して「はなかみ男爵」 という言葉を思いついたのだが、 用いる機会もないまま忘れてしまいそうなのでここに記す。 ここに書いておけば、もしかしたら、誰かが 「ハンカチ王子とはなかみ男爵」という題で ハートウォーミングなストーリィを書いてくれるかも知れない (知れなくない)。

本日のツッコミ(全2件) [ツッコミを入れる]

# うかい [こんな面白いこと(謎)が起こってるのに休むなんてー (とあおってみるテスト)]

# うんの [↑のお誘いとは関係なく、来ました。]


2006-09-07 (Thu)

また「涼宮ハルヒの憂鬱」の続きのDVDを借りてきた

この作品を知ったきっかけは、 野尻ボードで 長門有希の100冊が紹介された ことでした。 僕はちょうど「ディアスポラ」がネット界隈で話題になったのを きっかけにSF読みデビュー(遅い!)したてで、 「太陽の簒奪者」を読了したばかりだったし、 小林泰三さんのファンにもなったばっかりだったので、 長門有希の100冊リスト みて、結構よろこんでしまった。

「ところで、長門有希って誰?」状態でしたが。

なにを隠そう、筋金入りのオタクである(であるのか?) ことをご近所にひた隠しに隠して平穏な日常生活をおくる パパなものですから、アニメ作品に触れる機会など あるはずもなく……。

といいつつ、二日連続してDVD借りてきて観ている わけですが (妻子が「里帰り出産」で帰省しているからできる、とも言う)。

DVDの一枚目は伏線だけでおわってしまった感がありましたが、 二枚目でやっと動いてきたのか。 さすがは、筋金入りオタクむけ作品、念の入ったことで。 もしかしたら、主題歌にまで伏線を張ってあるのか。

ここまで観ると、なぜあのあと野尻ボードで 眼鏡っ娘談義になってしまったのかが、わかった気がする。

だが、ツタヤには二枚目までしかなかったようなので、 続きを見る機会はもう当分ないな。 どんな話だったんだろう。

ところで、いま「100冊」のリストを見て思い出した。 浪人時代、予備校の先生に 「『カラマーゾフの兄弟』は必ず読め。 あれを読まずに生きるな。」といわれたなぁ。 まだ読んでないなぁ。

トラックバックスパムくさいやつばっかり

ぼちぼちトラックバックがつきはじめたと思ったら、 スパムくさいやつばかり。

まだ無視できなくもない数だが、 RSSがゴミだらけになる前にトラックバックスパム対策の 導入を検討しておくべきか。 参照すべきはやはり、 「最近多発しているツッコミspamへの対策」 かな。

記念すべき 最初のトラックバック は、限りなくスパム臭かったんだけど、 かろうじて「自動車保険」というキーワードを絡めていたのと、 あと、「ようこんなとこ見つけてきたな」と感心したので残した。 最初のトラックバックでもあるしね。 他のは削除。


2006-09-10 (Sun)

「消失」まで読んだ

ジャケ写がエロい という言葉にまんまとつられて、 Just can't help it! のページ を見に行く。 ううむ、なんだろうな、この微妙に現実感の希薄な絵は。 ジャケ写じゃなくて、一番上のステージ写真。 とくに真ん中のひと。日舞仕込みなんでしょうか。

そういえば、昔みた「鴨川をどり」で、人間とは思えない動作をする人をみた。 舞妓さんやら芸子さんやらが大勢舞台でひらひらと舞うシーンだったのだが、 皆が同じように舞っているのに、 ひとり(「一体」と言ったほうが良いか?)だけ浮いた存在が。 きっと一番うまいひとなんだと思うが、真ん中で舞っていたひと。

扇は、人の手の制御下にあるとは到底信じられないくらい、ひらひらとカオティック な運動。大気中を落下しているようにも見えるが、 いつまでたっても落ちずにひらひらしている。 その中心では、すこし腰を落とした姿勢の人が、 まるで、ろくろの上に乗っているかのように、音もなく回っていた。

「ひとりだけ、人間に見えない人がいる」と当時思ったのだが、 もしかして……TFEI 端末?

というわけで、先日ハマってしまった涼宮ハルヒシリーズは、 DVDをまっていたら何時のことになるかわからないので、 原作小説で読み進めている。

「憂鬱」、「溜息」、「退屈」と一気読みしてしまった。 最初にアニメ版から入ったおかげで、小説を読んでいる間も、登場人物は あの声でしゃべってくれる。

と、ここで一度スローダウン。 まあ、一気にすべて読みつくしてしまうこともないだろうというのと、 すこーし心配もあって。長門有希のこと。

彼女のファンは僕ばかりではないと思う。 小説を読んでいるあいだ、彼女が次に登場するのを常に心待ちにしている ようなところがある。登場しても、ミリ単位でしか動かないのだけど。 台詞の大半は3点リーダー(…)だし。

心配というのは、ほんとに余計なお世話でしかないと思うのですが、 この読書好き少女が、毎回期待通りの活躍をして、 なんというか、手垢のようなものがついてしまわないだろうか、とか、 なんとか。(ほんと、何様なんでしょうね、わたくし)

とまあ、勝手に偉そうな懸念を抱いて、続きに手が伸びないつもりで いたのですが、結局、今日郵便局に行ったついでに本屋へ行って、 続きを購入してしまった。 「退屈」の次は「消失」ですか。順番がわかりにくいな。

で、感想ですが、 「偉そうにも余計な心配して、すみませんでした。おみそれしました。」

最近おもうこと

やっぱり人間の世の中には、面白いことがいっぱいありそう。 これまでアンテナを極端に強指向性にし過ぎてきたせいで、 見逃してきたんじゃあるまいか。

「泣いたり笑ったりできるとこが、すてき〜」

おっしゃる通り。

おし、少しバイオリンの練習してから、掃除の続きだ。 あれはね、やはり、うたう楽器だと思うのですよ、 などと、似非悟り(一回目)。


2006-09-12 (Tue)

勝手 make

http://d.hatena.ne.jp/higepon/20060909/1157794886

昔、遅いパソコン*1 を使っていたころには、 いまのように LL な生活は想像できていなかった。

で、上の「勝手 make」はさらにびっくり。 でも、自分では思いつかなかっただけで、聞けば納得。

計算パワーは量的に、かつ、漸進的に増加しているわけですが、 それによって、オールド・タイプな人々(もちろん僕を含む) の「常識」は、あれもこれも壊されていくのだろうなぁ。 あ、前フリを使いわすれてた。 えと、量的な変化が、質的な変化をもたらすのであるなぁと。

僕が「常識」として、いま具体的に思い描いているのは、 「数値計算は専門家の仕事である」というやつ。 詳しくは、後で……書くときがくればいいなぁ。 (もう既にそっち向きに走り始めている人がいっぱいいそうですが)

*1 MSX2 → X68000(国産パソコン唯一の名機でした、と思う。知らんけど。)

もういっこ思いつきメモ

もはや、HPC はコンピュータ技術を牽引したりはしない。

これって、数字でばきっと示せるのではあるまいか。 リソース(お金・人員)比率を時系列でプロットしてみたり。 (それが「ばきっと」なのかどうかはアレですが)

キーボードがすべって、トンチキなこと書いてしまっていたので、消し。


2006-09-15 (Fri)

[Web] 日本語で上手な文章を書くには:10の「べからず」

日本語で上手な文章を書くには:10の「べからず」Playnote ニュースクリップ 経由)

まったくその通りすぎて、面白くて、かつ、笑えないのですが。

思い返せば、少なくとも僕が受けた学校教育では、 上で述べられているようなユダヤ人もびっくりな文章が よいのだということすら、明には述べられなかった。 教授法さえも、暗示的。なにがしたいんじゃ。 (国語の先生の口癖は、「すべては読書量できまる」でした。)

文章の書き方について、はじめておそわった記憶は、 高校時代に通った予備校の英文読解の授業だったと思う。 外国人として英文を読むには、自然にまかせるのではなく、 使えるメタ情報は総動員すべきで、そのひとつとして、 文章がどのような構造でかかれることが多いかということを 教えてくれた。 なるほど、教材として選ばれている文章はそのように書かれている。

なんで、本来国語でならうべきと思われる、文章の構成方法を 英語の授業で習わなあかんのかと思ったことです。

そういえば、この日記には、 どこを探しても主張や結論のようなものが明示されていませんが、 これも英語圏な人からみるとミステリアスなんかなぁ。

ところで、リンク先の「10の『べからず』」がネタなんじゃないか という思いは捨て切れない。出来すぎてる。

サラリーマン忍術

というわけで、結論から言おう。 忍術は実在した、いや、すると思うんです。

あー、待って!帰らないで、お願い。

みなさん、「ゾーン」という言葉をご存知でしょうか。 ゾーンというのは、人が、ある事柄に没頭して非常に能率よく仕事をこなしている、 集中力の高い状態のことを指す言葉です。 とてもパフォーマンスの高い人というのは、 実は、自由にゾーンに入ることができる人なのかも知れません。

でね、ステレオタイプ的忍者のひとって、 ある術を行使するときには、印(イン)を結んで、 さらに何かこしょこしょと呪文を唱えるでしょう? あれは、日頃の鍛錬の成果を、いまこの瞬間に 100% 炸裂させるための、精神集中のための儀式なのではないか?

私も、さすがに、呪文ひとつでつむじ風を起こしてしまうような 「忍法・木の葉隠れ」とかをそのまま信じる気にはなれませんが、 自己ベストの跳躍でなければ飛び越えられない壁を、とっさの精神集中の術でもって ここぞと自己ベストを叩き出して飛び越える、 こんなことをいつも成功させられる人がいたら、 やっぱり常人離れしたすごい人ということになると思うんです。 忍者だ、忍者。

そういえば、そんな感じのひとをテレビで見たことがある。 なんというか、イタいめのコラムにとりあげられがちな人を登場させるのは 気が引けますが、あのイチロー選手です。野球選手の。

彼は、バッターボックスにはいり、まずあの有名な動作をしますね。 バットを「予告ホームラン」にはちょっと低いな、あ、あれですか、 「予告ピッチャー返し」的に振り上げ、袖をちょっと引っ張る。あの動作です。 あの動作が、バットでボールを打ち返すという作業に本質的に必要な 予備動作なわけがありませんから、あれは、 彼の精神集中のための儀式だと考えるのが妥当でしょう。 つまり、忍者が印を結んで呪文を唱えるのに相当するのが、あの作業なわけです。 (と、思います。) きっと、あの動作の直前までは、むしろリラックスするようにしていて、 あの動作の直後は、 我々素人にはちょっと無理なくらい集中されているのではないでしょうか。 まさに、「ゾーン」状態。

これに似たようなのは、実は、僕らだってやってたりします。

僕は、浪人生時代、大阪の中ノ島図書館で勉強しました。 若くて重要な時期を過ごしたこの図書館については、 いくらでも語れそうな気もしますが、とにかく西洋かぶれ丸出しに美しく、 奇妙で古い建物の図書館だと理解していただれば、ここでは十分です。

僕はこの図書館に篭って勉強したわけですが、 うーんと集中して勉強し、「あー、しんど(疲れた)」と思ったら建物の外へ出て 新鮮な空気を吸う。

つまり、あの見た目の不思議な図書館という空間が、僕にとってはそのまま 「ゾーン」のメタファになっていたわけです。 いい具合に異世界感をただよわせる素敵な空間だったので、 ゾーンのメタファとしては申し分がなかったと思います。

でも、いわば、これは初級忍術といわねばなりますまい。 熟練した者であれば、そのような大掛かりな舞台装置を用いずとも、 自由に術を行使できるべきなのありましょう。

実際、我々のようなデスクワーカー系理系サラリーマンにとって、 ゾーンに没入するのは非常に重要なことなのですが、 これが容易なことではありません。

自分の占有できるスペースは限られており、 周囲の人々と自分を隔離するものはなく、いつ話しかけられても、 いつ電話がなっても、いつメールがきてもおかしくない環境です。

いや、話しかけられるのも、電話がかかってくるのも、メールを読むのも 全然嫌いじゃないし、歓迎なんですが、だからこそ、 ゾーン状態を維持するのは大変むずかしくなってしまいます。

つまり、舞台装置的には「ここはゾーン内だよ」という暗示の効かない場所 で集中力を高めなければならないわけです。 となれば、ここは、忍者の印と呪文に相当するギミックを発明するのが よろしかろう。

紙と鉛筆系頭脳労働者ならば、「ノートを開き、鉛筆を持つ」を入る動作、 「ノートを閉じ、鉛筆を置く」を出る動作にしてもいいかも知れない。

重要なのは、入ってから出るまでの「ゾーン内」では、 可能な限り集中することだと思います。 そのためには、入る動作は十分暗示的である必要があると思われるのと同時に、 出る動作が必須で、かつ、瞬時に行えるものでなければならない。

あー、集中力が切れる!というときには、速やかにゾーンから退出して、 決してゾーン内では粗相をしない。きっと、これが大切。 そして、なるべくゾーン内にながく居られるように訓練していけばいいのでは ないでしょうか。

そこで、ちょっと思いつきました。 いま、僕は、会社ではPCを端末として仕事をしています。 ちょっと後先になりますが、スクリーンロックをかける動作を 「出る」動作として採用するのが良いかも。 会社でいま使っているのは Windows 2000 で、CTRL+ALT+DEL, Return で ロックがかかりますので、瞬時に出られるべしという要件は満たしています。

電話がかかってきたとき、ひとに話しかけられたとき、はたまた、 「あー、集中力がきれる」というときには、そのままにしないで、「出る。」 ゾーン内で決して粗相をしないためです。

で、入るときには、スクリーンロックを解除して「入る。」 ここではパスフレーズを求められるので、 「入る」メタファとしての機能を任せられそうです。 できれば、単なる暗証番号的なパスフレーズではなく、 思わずゾーンという亜空間に招待されそうな魔法の呪文を用意した方がいいかも しれません。呪文か。どんなのにしようかなぁ。

出る動作が瞬時に達成可能でなければならないのに対して、 入る動作は多少面倒でもいいのです。 むしろ、チャクラを練るくらいもったいぶったほうが効果がありそう。

でもなぁ、これだとメール読んだり、 ぶらぶら web ブラウズしたりできなくなるんだよなぁ。 どちらもゾーン内では「粗相」にあたる行為なので、隔離したいところ。

そういや、もうすぐ端末が linux に変わるらしいぞ。

ウインドウ・マネージャーに細工して、仮想画面をゾーン内/外に分離しては?

PCに触っている間はゾーン内、 PCから手を離しているときにはゾーン外という具合に分離できれば、 話は単純になるのですが、現実にはそうならない場合が多いと思います。

必須だとはいってもメールの読み書きはゾーン内でやるようなことではないし、 建前上はどうだか知りませんが、 Web ブラウザでぶらぶらいいかげんな散策をしてしまうこともある。

これは、仮想画面を複数持つウインドウ・マネージャーを使えば、 うまく分離できそう。

ゾーン内に相当する仮想画面には、 没頭したい作業に必要なアプリケーションのみを配置。 それ以外のアプリは、ゾーン外の仮想画面におく。

仮想画面ごとにテーマ(見た目の雰囲気)を変える機能ならもとからあるだろうから、 それも有効利用しよう。

あとは、入退出のギミックだなぁ。 ただ画面を切り替えるだけじゃなくて、瞬時に出られて、 入るのに儀式(パスフレーズ入力でいいと思うけど)が求められるような。

補足

ひげぽん氏の  firefox の「集中」モード のような機能は、 僕も前々からほしいと思っていました。 集中したいときには不要な機能をどっかにやりたい。 これと似たような要望だと思います。

ただし、やはり、ゾーンから出るときに長いパスワードを求める (これはペナルティ的意味合いだと思う)よりも、 入るときに儀式をやるほうがいいとおもう。

さらに、firefox 単独でモードを切り替えるのではなくて、 画面ごと亜空間へ……。


2006-09-19 (Tue)

メモ:TSO に関して。

http://www.nminoru.jp/~nminoru/diary/2006/08.html#2006-08-11

五月雨式に書くのは控えますとかいいつつ、全然控えられていないので、 反省中。いままでのやり取りをよくよんで、必要な文献もきちんと 調査して、ちゃんと書かないといけないなぁと思う。

いままで、ひとつも嘘は書いていないつもりなのですが。 (いくつか嘘かいていた。後述)

以下、忘れないように、気付いたことを、気付いた順序で。

[13] [うんの] 2006-09-19 10:08:57 より、

観測されるのは順序であって、各 load/store がそれぞれ global visible になった 瞬間に「あ、いまだ」と観測されるわけではありません。

観測されるべき、global visibility order が確定する瞬間なら存在する。 ストアなら、coherence domain の一部であるところの、キャッシュに書かれた瞬間。ロードなら、その後キャンセルされずにコミットするようなロード(微妙な書き方)命令において、ロード値がデスティネーション(たとえばレジスタ)に書かれた瞬間。

こっちを知っていなければわからない順序になっている(ように見える) ところが、誤解の種なんだろうか。

SPARC V8

V9 の参考文献リストをみるに、どうやら、SPARC V8 は 「Sindu 以前」 であるらしい(←たぶん、これウソ)。 で、実際に SPARC V8 の TSO に関する記述は混乱している 可能性が高そうだ。これは、引用された部分からもうかがえる。 しまつた。

(追記)「混乱している」というのは、不必要な説明があるという意味。 TSO の定義はハードインプリに関する説明とは切り離しておこなわれる べきなのに、必須でないインプリに依存した説明になっていそうだ ということ。

その点、(そういうのに比べると)P.O.O. は笑えるくらい論理的。 直接関係ないけど、Storage Addressing のところを読んだときには、 目から鱗が落ちる気持ちだった。

(追記2)いくつか嘘かいてました。 Memory transaction という言葉はでてくる。 しかし、それが何なのかははっきりとは示されていないようにも。 もう一度きちんと読む必要があるが、 model として、キャッシュがなくて、だけど、ストアバファがある、 メモリは instruction の指定したサイズの load/store を直接うけつけることができるようなものを想定して、 その上で記述されているような感じ。 そうすると、global visible point は一点にみえる (store forwarding が微妙)

当然、キャッシュを持つシステムでは、物理的にはあちこちに global visible point が発生するが、そんなもんはインプリ依存だから 知らん、というわけでしょう。きっと。

Memory order の定義については、単に僕がまちがってた。

本日のツッコミ(全1件) [ツッコミを入れる]

# うんの [「表示可能な文字数を 1000 → 2000 に増やして」も足りなかったみたい。なんてこった。]


2006-09-20 (Wed)

TSO と store forwarding

追記:まとめというか、続きが2006-09-22 にあります。

http://www.nminoru.jp/~nminoru/diary/2006/08.html#2006-08-11

nminoru さんのところに押しかけていって、議論を迷走させてしまった件について。 私の議論スキルの無さが露呈してしまったと思います。 この件について、私は、 きちんと人に説明できるほどには十分理解していなかったというべきかも知れません。

本来の争点からずれたところで話を長引かせてしまい、かつ、 いくつか誤ったことを言ってしまうという痛い間違いも犯してしまいました。 我ながら議論が出来ていない。 また、きちんと文献にあたっていれば防げたはずの間違いをしている点は、 不誠実だったと思う。 こんなことにつき合わせてしまい、nminoru さんには申し訳ないことをしました。

問題点:Store forwarding は load - load 間の追い抜きを発生させるか。

問題となったのは、TSO (Total Store Ordering) で、かつ、 Store forwarding を採用しているシステムの場合、 後続の load が先行する load を追い越してしまうケースがあるのではないかという話。

プロセッサ 1        プロセッサ 2
1: Store [x] = 1    4: Store [y] = 1
2: Load r1 = [x]    5: Load r3 = [y]
3: Load r2 = [y]    6: Load r4 = [x]

上の例は nminoru さんの挙げられたものを借りてきました。 Store forwarding を行うシステム上でこれらの命令列を実行した場合、 r1 = r3 = 1 で、かつ、r2 = r4 = 0 という結果が得られる場合があります。

結論からいうと、これはなんら TSO に違反していません。 1: の store は、プロセッサ 1 上で実行された時点では Store buffer に格納されるだけであって、ただちには global visible になりません。 後続の 2:, 3: の load は、1: の store が global visible になるのを またずに実行可能。また、load は実行された時点で global visible になります。 *1

つまり、 プロセッサ 1 の memory operation は 2: → 3: → 1: の順で global visible になったのです。 (これが唯一の解ではなく、プロセッサ2が 5: → 6: → 4: でもいい)

私は、これで話が尽きていると思っていた(いまも思っている)ので、 これに対する反論にあまりきちんと対処できていませんでした。

反論:3: → 1: → 2: でないとおかしい。

これに対し、nminoru さんは、global visible になった順序は 3: → 1: → 2: だったと考えるほうが自然だと言われました。 2: の load は、1: の store 値を受け取っているのだから、 1: が global visible になった後に置かれるべきであるということでしょう。

こう考えると、3: の load が 1:, 2: の両方を追い抜かしたと 考えなくてはならなくなります。1: を追い越すのだけならまだしも、 2: を抜かすというのは TSO に違反しています。 本当にこのように考える必要があるのでしょうか?

追記:こう考えるためには、Store 値が global visible になるのと、local visible になるのが同時であるという類の追加規則を仮定する必要があります。 なぜ、勝手に規則を追加するの? 既に矛盾のない体系に、あらたな仮定を追加することによって矛盾を引き起こしていますよ。

この案の欠点は、

  1. 2: が 1: を追い越したという自然な解釈を採用すればすべて解決するのに、それをしていない点。
  2. それにより、load が load を追い越すケースが存在するという例外規則を必要としている点。
  3. その例外規則だけではハンドリングしきれないケースが存在する点。
  4. (追加)2: は 1: よりも後に global visible になる筈だという暗黙の規則を、どこからともなく持ち出している。

あたりでしょうか。 とくに、3番目がクリティカルなんじゃないかと思うのですが。

これは、命令列をちょっと変更すると明らかになります。

1: Store [x] = 1
2: Load r1 = [x]
3: if (r1 == 1) {Load r2 = [y]}

こうすれば、nminoru さん的世界観でも、3: は 2: を抜かせなくなりますが、 これでも r1 = r3 = 1 で、かつ、r2 = r4 = 0 という結果は得られるはずです。

仕様書には、たしかに、Sigle port memory に memory transaction が到達したところで memory order が観測されると書いてあります (SPARC-V8 の場合) が、ここでいう memory transaction は、 純粋に仮想的なものであって、 実システムにおけるどのような処理に相当するのかは自明ではありません。 (Model に反しない限り、どのようにインプリしてもかまわない)

述べるべきだった事柄は、だいたい以上の通りなのではないかと思います。

反省

なにより、nminoru さんがきちんと文献を確認しなおして書かれているのに 対し、私は手元に文献がない状態のまま誤ったことを書いてしまっていた箇所が いくつもあります。これはとても不誠実な態度だったと反省しています。 すみません。

観測されるのは順序であって、各 load/store がそれぞれ global visible になった 瞬間に「あ、いまだ」と観測されるわけではありません。 結果的にプログラムがどう動いたか(だれの、いつの時点の store 値を load が受 け取ったか)を通じて、順序が観測されるのです。

これは正しいのですが、TSO memory model を out-of-order 実行システムで実現した場合の話になって しまっています。 つまり、余計な、関係の無い話だったと言えます。 →修正:普通にただしいことを書いているよな。

V8 が手元になかったので(手抜きですみません)、V9 と言葉使いが変わらないもの として。

SPARC の用語定義においては、Memory order と memory model (こちらは global visibility に関する) global visiblility order とは別の概念です。

Memory order の方は、ほぼ dependency order / self-consistency と同じ意味で 定義されています (V9 manual で D.2)

これは、本気でまるごと嘘っぱちを書いてしまいました。 すみませんでしたとしか申し上げようがありません。

> SPARC V9 Spec も memory ordering は memory transaction がメモリに届く順序 だと規定しています。

そんなことないでしょう。SPARC V9 では、D章にトランザクションは明にでてこない はず。(8章が description, D 章が形式的定義となっています)

これも嘘を書いてしまいました。 SPARC の仕様には memory transaction という用語がずばりもちいられています。 ただし、これが実システムにおける何に相当するのかは明らかではありません。 Model は Model だから、インプリは指定しないということなのでしょう(以下)。

The SPARC-V9 architecture is a model that specifies the behavior observed by software on SPARC-V9 systems. Therefore, access to memory can be implemented in any manner, as long as the behavior observed by software conforms to that of the models ... (Chapter. 8 Memory Models, 8.1 Introduction, SPARC-V9)

現実問題として、メモリトランザクションというと、普通はプロセッサチップから メモリバスへ発行されるトランザクションを彷彿することが多いと思われますが、 これと memory model は無関係です。 このことが念頭にあったので、上の「そんなことないでしょう」発言をしてしまいま した。

あきらかな嘘っぱちを書いてしまったのは、以上2点なのではないかと思いますが、 他にも議論にとって有効でないことを書き散らすなど、 反省すべき点がたくさんありました。

反省材料として、私にとっては価値があったのですが、 nminoru さんにはご迷惑だったと思います。お詫びします。

*1 「また、load は実行された時点で global visible になります。」にタダで同意してもらえないんだろうなあ。というわけで、ここが要説明ポイント……かなぁ。


2006-09-22 (Fri)

この日のエントリだけ、やたらとコメントスパムにあっていたので、しばらく隠していました。 ためしに隠すのをやめてみますが、まだなにも対策していないので、またスパムの嵐にあうのかも。

あったらそのとき考えます。

私は、SPARC-V9 の TSO 定義をこう読んでいます。*2

http://www.nminoru.jp/~nminoru/diary/2006/08.html#2006-08-11 のコメント [19] )

まず最初に。 SPARC-V9 のメモリ・モデルは、 ソフトウエアから観測され得る振る舞いを規定したものであって、 特定のインプリメントには依存していません。 このことが、この仕様の価値を高めていると同時に、 ちょっとイメージのつかみづらいものにしてしまっている感はあります。

なお、「ソフトウエアから観測される」とは、 プログラムを実行した結果として得られる情報 (プログラムそのものと、その実行結果) から推定される という意味です。

TSO 等のメモリ・モデルは、 global visible order *3 に関する規則です。 にも関わらず、例えば、load がいつの時点で global visible になるのか、 そもそも、global visible とはなんなのか?という記述なしに、 TSO の説明が始まっているように見えます。

なぜなら、TSO メモリ・モデル全体が、global visible order を定義するからです。特定のインプリメントに依存しないように global visible order を定義する方法は、これしか無いように 思われます。

Global visible order について、 TSO のようなメモリ・モデルなしに(自明な事実として) 合意されるであろう事柄は、 「ストアが global visible になった後でなければ、 そのストア値は他の CPU からは見えない (load できない)」 だけでしょう。

この順序は、以下のようなプログラム片を用いて観測することが 可能です。(以降、メモリの初期値は 0 とします。)

 Processor-1            Processor-2
 1: Store [X] = 1    2: Load r1 = [X]

実行結果として、r1 = 1 が得られれば、(ソフトウエアから観測される、 (以下わざわざ書かない))global visible order は、 1: → 2: となります。r1 = 0 だったなら、2: → 1:。

意外かもしれませんが、TSO 等のメモリ・モデルなしに推定できる順序 (ソフトウエアによって観測される振る舞い)はこれだけです。

たとえば、次のようなプログラム片を実行した結果、 r1 = 1, r2 = 1 が得られたとしましょう。

 Processor-1            Processor-2
 1: Store [X] = 1    3: Load r1 = [X]
 2: Store [Y] = 1    4: Load r2 = [Y]

このとき観測された global visible order は、 1: → 3: かつ 2: → 4: です。1:, 2:, 3:, 4: の 4 つすべての global visible order として考えられる候補 (3! 通り)のうち どれだったのかは、ソフトウエアには観測できないことになります。 たとえば、2: → 4: → 1: → 3: だったのかも知れない。

ここで、TSO を仮定すると、1: → 2:, 3: → 4: の制約が加わるため、 考えられる組み合わせはもっと減ることになります。

再び、問題のケース

問題のプログラム片を再び持ち出してみましょう。 ただし、組み合わせを減らすために、Processor-2 の方に少し細工をしました。 メモリ・モデルは、TSO を仮定します。

 Processor-1         Processor-2
 1: Store [X] = 1    4: Store [Y] = 1
 2: Load r1 = [X]       Membar #StoreLoad
 3: Load r2 = [Y]    5: Load r3 = [Y]
                        Membar #LoadLoad ; TSO なら不要だが念のため
                     6: Load r4 = [X]

ここで、実行結果 r1 = r3 = 1, r2 = r4 = 0 のとき、 ソフトウエアから観測された global visible order がどのような ものだったか考えてみます。

まず、r2 = r4 = 0 と、 「ストアが global visible になった後でなければ、 そのストア値は他の CPU からは見えない (load できない)」 という自明な規則から、

 6: → 1:
 3: → 4:

が判明します。

今回、Processor-2 の方は、シーケンシャル・オーダー になるよう細工してあるので、

 4: → 5: → 6:

となっています。

ここまでで確定したのは、

 3: → 4: → 5: → 6: → 1:

です。まだ 2: の場所がきまっていません。(★)

ここで注意すべきなのは、 観測結果 r1 = 1 から global visible order について推定できることがらは 存在しないという点です。 自明な規則は、 「ストアが global visible になった後でなければ、 そのストア値は他の CPU からは見えない (load できない)」 でしたが、これでは Processor-1 内部に閉じた 1:, 2: 間の順序を確定することはできません。

しかしここで、TSO のメモリモデルより、

 2: → 3:

が決まります。

したがって、global visible order としては

 2: → 3: → 4: → 5: → 6: → 1:

が観測されたことになります。

Processor-1 の分だけとりだすと、

 2: → 3: → 1:

となっていますが、これは TSO メモリ・モデルを違反していません。

一方、3: → 1: → 2: 案は?

一方、3: → 1: → 2: とする案では、 どのような推定が行われたのことになるでしょうか?

上で(★)印をつけたところまでは共通でしょう。 つまり、

 3: → 4: → 5: → 6: → 1:

までが確定していて、2: の位置が決まっていない。

ここで、nminoru さんは、 どこからともなく

 1: → 2:

という規則を持ち出してきています。

どこにも書かれていない規則を適用し、 「3: → 1: → 2: になってしまった、TSO 違反だ!」 と主張しているように、私には思えます。

*1 SPARC-V9 の TSO 定義はこう読むべきですとしなかったのは、自信のなさの現れだったり。

*2 SPARC-V9 の TSO 定義はこう読むべきですとしなかったのは、自信のなさの現れだったり。

*3 英語的には globally visible order と書くべきでしょうか。

π秒は 1 ナノ世紀

http://njb.virtualave.net/nmain0216.html#nmain20060922095828

もしかすると google 様が教えてくれるのではないかと思い、 聞いてみました。

http://www.google.co.jp/search?q=pi+second+in+century&lr=lang_ja

おお。

本日のツッコミ(全185件) [ツッコミを入れる]

Before...

# sdf2361 [Hell0, nice site and great work! Thx !!!]

# sdf2361 [Hell0, nice site and great work! Thx !!!]

# fr34edy [Hell0, nice site and great work! Thx !!!]


2006-09-29 (Fri)

[Web] コンピュータは人間を進化させるか: アラン・ケイ氏インタビュー

http://pc.watch.impress.co.jp/docs/2006/0925/high43.htmひげぽん氏 経由)

ちょっと Squeak に興味がわいた。 だけど、実際に触ってみるかは微妙。

しかも彼らはコンピュータ分野の専門家だ。 もし物理学の専門家が、マクスウェルやアインシュタインの 業績を知らなければ、学会追放ものだ。 しかしコンピューティングではエンゲルバートの業績を知らなくても 関係ない。なぜならこれがポップカルチャーだからだ。 パンクロッカーがバッハの功績を知らないようなものだ。 ポップカルチャーはバッハにまるで興味を持たない。 ポップカルチャーではアイデンティティと参加こそが重要だから。

半分くらいしか同意できないのだが、 それは、僕がエンゲルバートの名を知らなかったせいかも知れない。 *1 (または、僕が「コンピューティング」という単語が何を指す のかについて誤解している)

たしかに、コンピュータの世界では車輪の再発明ばかり繰り返されて いて、進歩が妨げられているのは確かだと思う。 悪いことに特許なんてもののせいで、再発明が余儀なくなっている 場合すらありますね。

過去1世紀の電子技術のほとんどは退行的だ。 というのは電子技術の多くは書くことより オーラルコミュニケーションを奨励するからだ。 昔、人々に読み書きを強いた多くのものは今は存在しない。 楽しみのために読まなければ、 恐らく必要になったときには読む鍛錬が足りていないだろう。 書くこともどんどん不要になっている。 将来はもっと、コンピュータが、 “学ばないこと”の言い訳になるかもしれない。 米国の多くの学校は、子供がGoogleで何かを見つけコピーすると、 それで学んでいると思っている。 しかし私は、子供がそれについての作文を書かない限り 学んだことにならないと主張している。 作文は思考を組織化する。 単に博物館の展示物を集めるだけではない。 しかしほとんどの学校はその違いを分からない。

だから、理想的未来は人々が今日よりも、 よりよく考える未来だが、ありそうな未来は、 人々がよりよく考えないでしかもそれに気付かない未来かもしれない。

たしかに恐ろしい。

新人のころ、あるテーマについて調査し、 調査結果をまとめた資料を作成するという課題を与えられたことがある。 同期のヤツが、資料中の単語がおかしいことを指摘されたときに、 こう言ってのけやがった。 「これは Web で探してきたものをコピペしただけだから、 間違っていないはずです。」

ともかく、既にアラン・ケイ氏に見放された大人ですが、 まずは、大人がかわらなくちゃ、ってことで。

*1 そんな僕でも、フォン・ノイマンやチューリングをしらなかったらまずいと思うけど。

メモ:IA64 のメモリモデル

IA64 に触れる機会はないんじゃないかと思っているのですが、 折角なので読んでみました。

http://developer.intel.com/design/itanium/downloads/251429.htm

ざっと読んだだけですが、 SPARC-V9 を知っている人なら以下の説明でほぼ把握できるのではないかと思った。

  • 通常の st, ld は RMO
  • st.rel の直には暗黙の Membar #StoreStore がある(TSO の store に似ている)
  • ld.acq の直後には暗黙の Membar #LoadLoad|#LoadStore がある (TSO の load と同じ)
  • Membar #StoreLoad が必要な個所に用いるのが mf 命令

RMO と TSO の折衷案として、とてもよく出来ているように思う。


2006|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|08|
2010|01|02|03|05|06|07|10|11|
2011|03|08|
2012|02|04|07|08|10|
2013|01|02|03|05|06|08|11|12|
2014|01|02|05|06|07|08|09|12|
2015|01|02|03|04|
Categories 3imp | Card | Cutter | Dalvik | Euler | Football | GAE/J | Hand | Haskell | Re:View | Ruby | Scheme | TQD | Tiger | TigerBook読 | UikiTeXi | Verilog | Violin | Web | parconc | tDiary | お勉強 | エントロピー | ツン読 | | 将棋 | 政治について | | 模写してみよう | 確率論 | 設定など | 雑文 | 音声