C-x C-m c で、Coding system for following command というのを指定することができる。
これで文字コードを指定して、C-x C-f とかすれば OK.
もう開いちゃった場合は、C-x C-m r で buffer を revisit with specified coding system することができる。
しらなかったよ。
May 2007 Archives
なぜFreeBSDか というドキュメントが IBM developerWorks のページに載っていた。
おもしろい。
FreeBSD Install & Tuning memo というページも見つけた。vinum の設定とかがわかりやすく説明されており、けっこういい感じだ。
いまどき ccd 使ってる場合じゃないのかな...
Dell の、Pentium4 なマシンをもらったのだが、こいつがくせ者で、network boot をするためには、BIOS setup で、Network controller = ON ではなくて、Network controller = ON with PXE というのにしなきゃいけなかった。
そんな選択肢があるなんて、ふつう思わないって！
ま、そゆわけで、無事に動きましたが。
3.06GHz Pentium4 HT で、533MHz のRDRAM がささっており、当時としてはけっこう気合いの入ったマシンだ。
8時40分くらいにスタートで、飯田までは自転車で行ったことがないので、6時に宿を出ることにして、5時頃起きて、荷物をまとめたりとか、準備をがさごそ。そうこうしているうちに6時を過ぎてしまい、フロントの支配人さんから「朝ですよー」と内線がかかってくる。ご親切、いたみいります。
昨日まで、飯田へはどうやっていこうかなー、と思ってちょっと迷ってたのだが、夕方県道18号を走ったときに、18号経由で行くことに決めた。18号は、天竜川の東側を走る県道で、ちゃんとセンターラインがあるところもあるが、場所によっては崖っぷちで、自動車のすれ違いがやっと、というところもある。しかし、けっこうフラットで走りやすいし、景色はいいし、舗装状態も思いのほかよいのだ。片道 35km.
フロントに荷物を預けて、飯島駅前から日曽利橋へ向かって一気に下る。天竜川沿いの谷間には視界が悪くない程度の朝靄がかかっており、その中を突っ走るのは非常にいい感じだ。18号に入ってしばらくすると朝日がさしてきて、木漏れ日がきれい (写真は昨日のだけど)。
中川村に入って、淡々と走る。下り基調であり、けっこう快調だ。地図なんか持ってないので、途中川の西側にわたるところでは道を間違えたんじゃないかー俺ー、と、ちょっとびびったが。
川を渡って松川町。すぐ東側に戻る。松川から豊岡村あたりは、高校時代に歩いたこともあり、ちょっぴり懐かしい。松川町はすぐ終わりだ。で、豊岡村に入ると、道も広くなって、わりと街中を通る感じになる。学校にいく小学生に挨拶されたりしながら、35〜40km/h くらいでガンガン飛ばす。途中で、中学生くらいの、ドロップハンドルの自転車に乗った少年が「うお、なんかすげえのきた！」みたいな感じで目を丸くしてた。そりゃまあ、気合い入りまくりのチャリで気合い入りまくりの奴がぶっ飛んでいくのを見たことはないかもね。でも、今日は 10km 先で日本一速い連中が世界を相手に大暴れするんだぜ?
豊岡村から喬木村。喬木村は一瞬で突き抜ける感じで、すぐ弁天橋だ。弁天橋からはすぐ、TOJ の周回コース。そのまま天竜川沿いを突っ走る。
おお! 補給地点の看板が!!
で、そのまま山岳ポイントへ。途中で地図をみてるおじさんに声をかけて、「どうぞお先に」と先を譲るが、逆に譲られてしまって引くに引けず、ガンガン上る。マジでしんどく、途中で一度脚をついてしまった。一応おじさんには追いつかれずに逃げ切り、山岳ポイント手前で家族連れを追い抜く。山岳賞だぜイェーイ！とか、そういう感じではなく、これ12周もすんのかよ、という心境だった。
山岳ポイントで、スタッフの人に観戦マップをいただいた。とりあえず一周するかー、ということで反対側へおりる。山岳側のコースは広域農道なんだが、景色がすごいんだ！写真とらなかったけど。
途中間違って 256 号線を下ってしまって、うおー、こんな急勾配で狭いワインディングを集団で下るのか、プロはすげえぜ！と感心していたら、やっぱり違う道だった (笑)。急、といっても、せいぜい 7% くらいだろうか、上り返して正しいルートに戻る。がーっと走って、弁天橋のところに戻って、一周。そのまま水神橋まで。交通規制前で、周回コースを出る車が列を作っていた。
どこで見ようかなー、と迷って、結局駄科駅から川を渡ってきたあたりに落ち着く。近所の人たちがぞろぞろ出てきて、いい感じだ。そのうち小学生やなんかも、大挙してやってくる。そりゃ、近所でこんなのやってるんだったら、授業なんかやってる場合じゃないっすよ。
最初の周回がやってくるまでにけっこう時間があって、近所のひとたちといろいろ話す。一番感動したのは、近所のオヤジが「最近女房と、あれか？イタリアか？自転車のレース、テレビで見てるんだけどよ、あれ、めちゃめちゃ面白いな！」と話してくれたことだった。日本でどうしたら強い奴が育てられるか、そんな話で大いに盛り上がる。
そうこうしてるうちに先導車がやってくる。さあ、盛り上がって参りました！！
先頭は福島、柿沼とあと外国の誰か (笑)。うおー、平地での逃げなんか、速すぎて写真とれませんよ！ (↓というわけで、QuickTime Movie とってみた。クリックすると再生する)
応援の小学生たちの前を通り過ぎる集団。
なんかこう、あー、俺の街にもこうやってレースがやってくるようになったんだ、と思うと、すごく嬉しかった。俺の住んでる街じゃないけど。
僕以前にも、18号を全力で駆け抜けていくサイクリストはいただろうし、
ロードマンかなんかに乗って、そういう大人に憧れる少年はいただろう。
だけど、それだけじゃ何も変わらなかったんだ。
この国じゃ相変わらず、自転車競技はトラック (＝競輪) だけで、
ロードレースなんて誰も知らなくて。
そこらのオヤジが、「自転車レースって面白いな！」と大興奮でしゃべったりとか、テレビの中継を見て沿道に出てきたオバチャンが「山岳ポイントって何?」と、UCI のポイント制度について僕に説明を求めたりとか、中学生と引率の先生が、はじめて見る (停まっている) ロードレーサーを見て僕にいろいろ質問したりとか、小学生たちが目の前を通過する集団の迫力に息を呑んだりとか、
ああ、こうして世界は変わっていくんだ、と思った。
そしていつか、この街から未来の日本人レーサーが出るんだ。
これだけ大胆に道路を封鎖してレースをやる、というのは、この国ではとても大変なことだと思う。行政と住民の協力を取り付けることが、どれだけ大変だっただろうか。
それでもレースを誘致して、市のイベントとして育てたい、
という飯田市の決断には敬意を表したいと思う。
今年は美濃ステージができて、来年また、新しいステージが増えて、いつか Tour de France みたいに、全国の市町村が誘致合戦をやるようになったら、最高じゃないか。
僕らにできることは少しずつだけど、たくさんある。
そう、たとえば、ちょっと遠くのレースでも頑張って応援にいって、地元の人たちと自転車の話をしたり、それだけでもいい。
で、レースの話に戻ろう。
先頭の逃げは一旦4分差ほどが開くものの、徐々に後続が追い上げてくる。
僕は、そばで見ていた地元のおじさんに、県道1号からぐるっと上の方に回り込む道があることを教えてもらって、途中から山の上に移動することにした。道があることを教えてもらっただけで、道は教えてもらわなかったので、だいぶ迷ったのだけれど、景色がとてもよくて、それはそれで楽しいサイクリングだった。山を越えることになって、坂がすごかったけれど。
途中で通行規制の看板を見つけて、あー、道あってたんだー、と思う。
コースへ向かって下る途中で、農家のおばちゃんたちと雑談しながら、遠くを通過する集団を1枚。
山の上だったが、下から歩いて応援にきている人たちもかなりいて、ここでもいろいろルールやら自転車について聞かれた。
しばらくすると下の方で歓声が上がって、選手が上がってくる！山岳だぜ！イェイ！
先頭は福島・柿沼。
集団も上がってくる。
集団の傍らには脱落していく選手もいたり、
遅れていきながらも必死に食い下がる選手たちもいる。
後続集団を待つ浅田監督。本物の浅田監督が乗ってるぜ！うおー！
一緒に応援してたみなさん。自転車に乗るわけでもない、ふつうの人たちなんだけど、すごく熱かった。
レース終盤、リラックスした雰囲気の日本人集団。
それから三船選手。結局最下位だったけど、マジでかっこよかったです！！
山を越えるのはしんどいので、1時半ごろ、交通規制が終わってからコースを下って、そのまま来た道を戻る。応援の人たちはもういなくなっちゃってたけど、片付けをしている警備のスタッフや、追い抜いていく車の人たちが手を振ってくれたりするのがなんだか、嬉しかった。
途中のお店で玄米パン (堅い蒸しパンなんだけど、あれって東京にはないのかな? ちょっと甘くて、僕は大好きで、こっちで見かけたら必ず買います) を買って、食べながら走る。お昼食べてないし。
帰りの 18 号は上り基調。特に、中川村に入ってから、長い長い上り坂がある。
坂の下で、農家のおじさんが、「おー、がんばれよー！」と声をかけてくれた。
ありがとう！そのひとことだけで、僕はいくらでも上れます。
たとえボトルの水が空になりかけていても。
これは中川村から望む中央アルプスで、
これはたぶん、飯島町に入るか入らないかのあたり。
自転車っていいな、と思った。
見ず知らずの人が励ましてくれて、
上りはきついけど、その先にはかならず下りがあって、
同じ道を何度走っても、そこは決して同じ景色ではなくて、
コーナーを曲がった先には、とても写真にはできないような、
眩しい風景が広がっているんだ。
(ここで終わるとちょっとかっこいいんだけど、あとは、ちょっと蛇足)
日曽利橋を渡って、飯島駅のそばの踏切まではひたすら上り。
テンションはすごく上がってるんだけど、脚がついてこないので、
39x27 をゆっくり回して上がる。
復路もだいたい 90 分だった。ちゃんと計ってないけど。
宿で荷物を受け取って、お風呂に浸かる。
日焼けがすごくて、腕はお風呂に入れられなかった。
宿の人にも「焼けましたねー」って。
ちょっと早い電車に間に合いそうだったので、急いで駅へ。
飯田から歩いてきた、というおじさんと出会った。
僕は朝6時に、ここを出発して、飯田へ向かい、いま戻ってきた。
彼は朝6時に、飯田を出発して、いまここについた。
歩くのもいいな。
それぞれの、旅。
GenBank とかの、共通の features の書式。
http://www.ncbi.nlm.nih.gov/projects/collab/FT/index.html
http://www3.ebi.ac.uk/Services/WebFeat/
先週のこと。
TOJ 観るために、八ヶ岳から諏訪湖、有賀峠を越えて飯島で一泊。翌日の朝飯田まで行って観戦して、飯島へ戻って電車で帰京した。
富士見高原から、中央道諏訪南 IC へ向けて、八ヶ岳ズームラインを一気に下る。ここの道は気持ちいい。ただ、前後に自動車がいたりするので控えめで、あまり飛ばさない。だって、目の前で自動車に思い切りブレーキ踏まれたら、突っ込むしかないからな（笑）。
国道20号へ出て、諏訪湖までは下り基調。途中から県道で、杖突峠の152号線と別れる。道路に鳥居があるなー、と思ったら諏訪大社だ。
有賀峠の入り口は唐突に現れた。残り少ないボトルの水を気にしながら上り始めると、家並みはすぐ途切れ、諏訪湖が見えた。きれいだ。
しばらく峠の上りなんか、まともに走っていなかったのでけっこうしんどかったが、それでもわりとすぐに頂上についた。
頂上から辰野方面はゆるやかな下り。自動車もほとんどいなくて、のどかな田園風景のなかを 45km/h くらいで快調に飛ばす。最高に気持ちよかった。辰野からは天竜川の東側の県道を伊那市内まで。交通量も比較的少なく、アップダウンも少なくて走りやすい道だった。361号で天竜川を渡って、153号で沢渡へ。沢渡で昼食。みのりや、最高っす。
沢渡から旧道で駒ヶ原へ。あとは153号をひたすら南下して飯島。まだ14時前だったが、宿にチェックインできた。わーい。
宿の部屋からは電車が見えるんですよ。1時間に1往復くらいで、2両とか3両なのでたいしてうるさくもなく、のんびりしていい感じだ。
で、クールダウンで飯島町内をのんびり走ってきた。
ちょうど田植えの始まった田んぼに山が映ってきれいだったり、
おきまりの場所にもいきました。新しい橋が架かるみたいだ。
吉瀬から県道18号を日曽利方面へ抜けて、日曽利橋を渡って戻ります。
夕食はお決まりの、飯島食堂。もう、マジ最高っす。
火曜は八ヶ岳から諏訪湖、有賀峠を越えて辰野へおりて、伊那市街を過ぎて沢渡の「みのりや」で昼食。
沢渡から旧道で宮田市街を抜けて、153号経由で飯島まで。食後はペースががた落ちでした。
75.62km @ 26.9km/h (2h48m30s) odo 3190.4km
累積距離は、クールダウンで飯島あたりをぐるっと 15km ほど走ったので、それも込み。
水曜は Tour of Japan の南信州ステージを見に行ってきた。飯島から県道18号線を南端まで往復と、TOJ の周回コースを1周。
71.00km @ 24.9km/h (2h50m29s) odo 3274.5km
TOJ のことは、また別のエントリで書こうと思う。
最近、山手線の渋谷駅のホームに、こういう感じのやる気のない駅名標が貼り付けてあるんですが、どうしちゃったんだろう... ちゃんとした、アクリル板でできたやつはどこへ?
ええと、旅に出ます。
明日の夜までオフラインです。
みなさんさようなら。
杖突峠は平均斜度 10% 越えですか。
荷物背負ってそれはつらいので、やめにしよう。
有賀峠ならいけるかなー。いってみるかー。
荷物はだいぶ削った。
- ノート PC
- シャバの服 (いちおう短パンだけ残した)
といったアイテムは一切持って行かないことに。PC なんかは、帰宅した後のメールの数さえ想像しなければ、どうってことないのだが、後者はけっこう決断力が必要だ (笑)。つまり、財布と携帯電話と、本当に最低限の着替えしかもっていません。
そういえば、なんで平均斜度がわかったかというと、最近は wikipedia で峠の名前ひくと、出てくるんですよ。すげえ便利だな。
久しぶりに自転車乗った。しかも八ヶ岳南麓。
身体が完全に坂の乗り方を忘れており、えらく苦戦した。
県道17号に、新しい橋が開通しており、非常に気持ちいい。以前はこの下の道を下って上がって、そりゃもう大変だったのだよ。橋の上からの眺めもよかった。しかも、逆方向だと、正面に富士山が見えるんだ。
31.04km @ 24.2km/h (1h16m42s) odo 3100.7km
そういうわけで、先に研究会メモを載せちゃったのだが、金沢行ってきた。
残念ながら旅費が出ないので、コストダウンを図って、
- 往路は急行「能登」で、上野ー長岡ー金沢
- 復路は普通列車で、金沢ー糸魚川ー松本ー高尾
という予定を立てた。これだと、往路が9000円ちょっと、復路が7000円弱で、宿代が4000円弱なので、2万円に収まる計算だ。わお。
「能登」は、当然ながら寝台列車ではないが、むかしの特急列車の車両 (489系) を使っており、なかなかよかった。決して新幹線みたいに快適ではないけれど、ボックスシートを占拠して横になってしまえば、なかなかのものだ。普通列車のボックスシートより座面が長いのか、いつもの中央線普通列車より断然快適。
高崎まではうとうとしていて、高崎を出て、八木原くらいから記憶がない。目が覚めたら富山あたりで、強風のため遅れている、とのこと。ありがたく眠らせていただいて、35分遅れくらいの、7時10分ごろ到着。駅構内のパン屋さんで朝食。激うま。
金沢は天気が不安定で、ときどき嵐みたいに降ったり吹いたりだったのだが、そういうのは僕がスターバックスで書類と戦っていたりとか、会場に着いてぼーっとしていたりとか、そんな時に限られており、その合間を衝く形で武家屋敷の町並みだとか、金沢城址なんかをみてきた。全般的に、非常に文化的な感じの街で、非常によい。そういえば駅の建物も、なんかすげえカッコイイんですよ。
写真は金沢城の、五十間長屋。で、城の近くのラーメン屋で、鍋焼きラーメンとカレーのセット、というのを頼んだ。猛烈にお腹がすいてたしね。しかし、ラーメンは普通にゆでてました。残念。
午後は発表で、夜は懇親会で、その晩はホテル。
布団で寝られるって素晴らしい。寝坊したけど。
翌日も午前中は、若干寝坊して後輩二人の発表を聞き損なったものの、お昼まで研究会。
終わってから駅へ行ったら、もう普通列車では帰れない時間だったので、糸魚川まで特急に乗る。特急券が1200円くらい。糸魚川の手前、親不知のあたりは線路が海岸を通っており、いい景色だった。
糸魚川から大糸線。南小谷まではディーゼルだ。キハ52というやつで、糸魚川の駅に停めてある3両で国鉄時代のディーゼルカーの3種類の塗装が揃っており、JR西日本、なかなかやるな！という感じ。キハ52は、かなり昔の車両なわけで、懐かしい感じでよかった。景色もいいしね。そういえば、窓際のテーブルの下には昔懐かしいセンヌキがついていた。これって、最近ないよね?
大糸線は久しぶりだ。南小谷からは電車。信濃大町で乗り継いで、松本へ。北アルプスの上の方はまだ、かなり雪が残っており、よい眺めだった。
松本で、車掌をしている後輩と会う。久しぶりにきたら、松本駅が変わっていて、びっくりだ。
松本から甲府行き、甲府から高尾行きに乗り継いで東京へ戻る。松本駅で、月見五目なんとかご飯、みたいなお弁当を買ったのだが、きのことか山菜とかがたくさん載っており、とてもおいしかった。松本に行ったら、また買おう。
ちなみに、写真はけっこう撮ったのだが、ほとんどフィルムで撮っていて、まだ現像してないので、そのうち載せる気になったら載せます。
寝坊しました。まあ、最初の発表は身内なので許しておくれ。
[ PE 直結型動的リコンフィギャラブルプロセッサ MuCCRA-D の提案]
MuCCRA-1 の結合網は island style.
結合網は重要なファクタなので、直結型も作ってみることにした。
Nearest neighbor mesh ではあまりに柔軟性が低いので、ふつうはちょっと遠くへ行く線とかも引いておくが、いずれにしても直結。
IMEC の ADRES とか、日立の FE-GA は直結型。配線領域の面積コストや、隣接 PE 間の転送コストは安くなるが、データ移動の柔軟性が低い。
Nearest neighbor だけではなく、ひとつ飛ばしの配線もはいっている。
配線がレジスタなので、載ってしまえば 166MHz とか出て速い！
並列計算機に似ていて、メモリにどうやってデータをマッピングするかで大きく性能が変わったりする? (井口先生)
→ そう。MuCCRA-1 では、競合さえ起きなければ問題ないが、MuCCRA-D ではどこに置くかが大きな問題になってしまう。
プログラミングは手動? つまり、手作業で並列化プログラミングしているようなもの?
→ 配線も含めて手動です。MuCCRA Editor で配線。
デッドロックしませんか (堀口先生)
→ turn model を使って、禁止ターンをする場合とか、下方向への転送をする場合にはレジスタを通さないといけなくなる。
MuCCRA-D も大きくなったら、レジスタを増やしてやれば VC が作れる？
→ そういうことも考えてます。
我々のと近い気がするんだけど、必要な計算結果が違うところで生成されちゃって困る、ということはないか。(弘中先生)
→ あると思います。コンパイラをまだ作ってないからアレですが。
アーキテクチャ的な対策は?
→ ひとつ飛ばしの配線が意外と効くんじゃないかなー。ダメなときはコンテキストを切り替えるとか...
電力的には? (梶原さん)
→ MuCCRA-D のほうが食う。同じ問題をとくのにかかるエネルギも、全 PE がフルスピードで動いちゃってるので、いまのところ -D がだいぶ不利。
[動的再構成可能プロセッサ Vulcan2 とそのソフトウェア開発環境 ISAcc に関する研究]
ASIP: application specific instruction-set processor を、動的再構成可能にする。
32bit RISC core に RDP (reconfigurable datapath) がついた構成。
ISAcc は C プログラムから、普通のコンパイルとあわせて命令セットの合成を行う。
64PE から 128PE になると急に効くのはなんで? 比較的小さいデータパスを使いそうだから、64 くらいあれば幸せになれそうなんだけど (梶原さん)
→ ISAcc が Vulcan-1 (128PEs) 用のコンパイラなので、他の configuration ではいまいちかも
命令ライブラリとパターンマッチングしてコードを作る、というところで、ライブラリが 128PE 用になってる感じ?
→ そうですね。ライブラリが充実すれば。
カスタム命令と通常命令の EXE ステージは並列実行できない?
→ いまのところそうなっているが、それも検討中。
Configuration data のロードは multicontext で、PE が持っているのか、それとも毎回配られるのか (ふんがさん)
→ まだ決まってません。Vulcan-1 では前者で、メモリが大きくなってしまったので、後者にしようと思ったが、遅延が隠蔽できなくなってしまった。
ALU じゃなくて LUT なのは?
→ ALU based なやつも検討に入ってます
[高速並列画像処理用再構成可能プロセッサエレメントの提案]
3D モデルを使った画像認識。いい環境条件ではそれなりにできるようになってきたが、条件に対してロバストではない。そこで、3D モデルをいろいろな条件でレンダリングしたものを大量につくって、それと 2D 画像を照合する方法を考える。レンダリングを高速かつ大量に行えば、うまくいきそう?
[ 通信状態に基づくパケット毎自己再構成を用いた動的再構成プロセッサ搭載クエリトランザクション高速化装置]
日立中研の磯部さん。
データベースなどのネットワークアプリケーションで、クライアントとサーバの間 (ルータの中とか) に置いて高速化を実現するような appliance。たとえば、キャッシュをしたりとか、データベースへの挿入要求をいくつかまとめてからサーバに送ったりするようだ。さまざまなサービスに対応できる柔軟性と同時に、ルータなどに内蔵するために小型省電力であることが求められる。
通信データをメモリにバッファすると、ネットワークコントローラとプロセッサが同時にそこにアクセスするので帯域幅がもったいない → プロセッサに直結したい。
すべてのパケットがすべてのプロセッサを通過するのではなく、たとえば簡単なパケットは最初のプロセッサだけで (浅いパイプラインで) 処理を行い、複雑な処理が必要なものは複数のチップを使って処理能力を稼ぐ。
通信相手ごとに、いまなんの処理を要求されているかを把握しておき、どの回路を使うかを切り替える。構成情報は on-chip のキャッシュにあったり、外部の DRAM に置いてあったり。
TCP とかそのうえの HTTP とか SQL query を実装してみた。DDoS 対策にもなって、しかも本当に速くなるんだぜ！
チップは DAP/DNA-2 らしい。
キャッシュが当たれば 1 クロックで再構成、外れれば 10k clks. そのへんはどうなんでしょう? (泉先生)
当たり続ければ wire rate で処理できるが、外れはじめるとがくっと性能が落ちてしまう。入り口で順番を並べ替えてやればいいかもしれないが、それはそれで大変。
これ、サーバ系とはいえ、ストリーミングなので、データベース自体をやろうとしたら大変? (泉先生)
それはとても大変だと思う。
RISC core が載っているが、それは使ってない? (柴田先生)
使っていません。メモリの競合もあるので、使った方がいいか悪いか...
入力バッファを見て投機的にキャッシュに入れていくのはどう? (NEC 梶原さん)
そうですね。やりたいです。
[レーベンシュタイン距離を用いたテンプレートマッチングアルゴリズムのFPGA実装]
ふんが研の清水くん。
いま実装されているやりかたでは位置ずれに弱いので、レーベンシュタイン距離 (つまり edit distance) を導入。これは挿入・削除を許すので、位置ずれを許容することができるが、計算がしんどいので、ハードウェアで頑張って高速化する。
HSV に変換して色を検出。なるほどー。
色の境界線を 0度、45度、90度、135度の4種類の接線に近似して、この4つにそれぞれ文字を割り当てることで、画像を文字列化する (how cool!)。
Bach-C で書いた。Handel-C と違って、タイミングの制御はコンパイラがやってくれる。まじかよ。
水平・垂直の距離計算は並列にやる。で、そのセットを4つ並べて x8 。
FPGA で、2.8GHz Xeon の 4.8 倍くらい。
DP のテーブルはメモリに全部持ってしまっている? (おさな)
32x32 だからまあいいか、ということで入れてしまっている。
標識が回転しちゃっていることとか、文字の大きさがどうかとかあると思いますが (泉先生)
大きさに関してはある程度 tolerant であることを確認した。回転はこれから検証。
赤・青の検出のエラーレートはどれくらい? テンプレートの数は? (廣田先生? @ 九大)
色の識別は自分の実装でないのでノーコメントです。
いまは大分類の (赤い丸とか青い四角とか三角とか) しかないので、たいした数ではない。大分類したあとで小分類のを作っていかなければならない。評価にレーベンシュタイン距離を使っているので、計算量はテンプレートの数にリニアに比例するだけで済む。
[生化学シミュレータReCSiPにおける反応速度式共有化]
山田さん。
スライドがかっこいいぜ兄貴。
Solver Core は共有化しても 100MHz を確実に越えられる感じ。単体のときよりは若干複雑になるので、まあ、数 % は落ちるが。スライス数はだいたい 35% くらい減る。わお。
スループットが 14% くらい落ちてる。これはパイプラインピッチが長い方に揃ってしまうのが問題で、やっぱり入出力のところをなんとかしないといけないな。
グラフの同型判定はとても大変 (NP) だけど? (飯田先生)
まだ小さいので、exact に最適解が求まっている。
ずっと演算器が忙しい、というのが前提だと思うんですが、暇なのもあるんですか? (森先生)
システムがいろいろな式を含んでいるので、multifunction なモジュールを作ってやらないと面積が無駄になってしまう。
連立する式のセットを眺めたときに算数のレベルで簡単にできることとかありそうだよね (森先生)
ええと・・・方法があったら教えてください → 私もわかりません(笑)。reconfiguration と、共通部分式の抽出を組み合わせたりすると面白くなりそうですね。
木のマッチングはNPじゃなかったかも。でも、加算みたいな、左右が可換な演算はどう? (泉先生)
まだ考えていません。とてもむずかしい。
稼働率で評価しないといけないのでは? (飯田先生)
それはいまやってます... 半年くらいお待ちください m(__)m
[リコンフィギャラブルマシン SRC-6 を用いた海洋モデルシミュレーションの実装方法]
POP: Parallel Ocean Program
3次元球体上で流体基礎方程式を解く、気象予測とかの標準。
けっこう速いのだが、DMA が時間を食ってしまって Xeon に負ける場合がある。配列をうまく切り出したり、ブロックサイズを適切に選ぶことで FPGA が有利になる。
精度は single? double? (井口先生 @ jaist)
double です。64bit です。
わお。
ソフトウェアでも、ブロックサイズでずいぶん違うんだけど、やっていることは同じ? DMA の速度はどれくらい出ている? (井口先生)
演算量も workset サイズも一緒なんだけど、グラフに出ているのは関数1回あたりの時間なので。
DMA について、図 9 で送っているデータは 256KB で、300us だから 1GB/sec くらい。バンド幅としては悪くないですね。
いろいろ改良しても、やっぱり DMA が律速だと思うんですが (泉先生)
メモリインタリーブをするとコンパイラが別の配列として認識しちゃう。
オンボードメモリにデータをどう配置するかが問題ですだ。
[チップ間無線通信を用いた3次元動的リコンフィギャラブルデバイス MuCCRA-Cubeの提案]
天野研の斉藤君。無線方式 (誘導結合なのでベースバンド信号だ) での積層チップ。
MuCCRA-1 がベース。MuCCRA-1 は、PE 間結合網が island style.
RoMultiC 入ってます.
チップを重ねるときに、同じ向きで重ねるのでなくて、違う向きで重ねてやると配線長を短く使うことができるのではないか!?
重ねたチップを同一コンテキスト番号で駆動するか、個別に駆動するか。後者はパイプラインみたいにして使えそうだ。
MuCCRA-Cube は各 PE がインダクタをもっており、それで双方向通信する。コンフィギュレーションデータも、一番下の段から入って、無線で転送される。そのへんの面積オーバーヘッドは 10% くらいで済む。
でも、評価してみたら、あんまり配線長に効いてこないので、全部の PE にインダクタをもつ必要はないかも。
3次元方向に飛ばす場合に、どこまで飛ばす? 気合い入れすぎると相互に干渉したりしない? (泉先生)
基本的に隣接する、上下のプレーンに飛ばすことしか考えていない。
縦方向のほうが通信コストが高くなるから、同一コンテキストで動かすような密な関係じゃないほうがいいかもしれませんね (泉先生)
Multicore な感じとして捉えれば、同一平面の遠くの別のコアよりも、上下のプレーンの別のコアのほうが近い。
誘導の漏れを使って、隣と通信するようなことは考えてない? インダクタを switch matrix ではなく PE に持たせたのはなにか理由が? (森先生)
PE 間で接続したほうが、アプリケーションの実装が簡単になりそう。
電力削減って、どこのが減りそう? (堀口先生)
配線の電力が減りそうです。
インダクタによる通信のレイテンシは? (名古屋先生)
1GHz で通信して 1クロック = 1ns とかで OK.
[動的再構成型ハードウェアの階層型状態切り替え方式]
堀口先生。
PE 使用率がだいたい一定になるようにうまく均してやると消費電力が安定したり、削減できたりするのではないか、というのが motivation. 電力モデルを作ったり。
いろいろ調べていくと、idle な PE が意外と電力を食っていた! DRP はタイル単位でしか止められないので、状態遷移を細かい粒度でやるなら階層的な状態制御コントローラが必要で、もちろんそのぶんハードウェアコストが高くなるけど、いい感じだ。動作電圧なんかも制御できるようにするとより効果的、というか、リーク電流の割合が増えれば増えるほど、それは必須の処理になる。
いまの構成だと、PE を全部使えるほど配線がないので、このまま PE を増やすよりも、配線可能性を高めたりするほうが電力的にはよくなる? (柴田さん)
64PE 単位だとやっぱり粗すぎるかもね。
再構成をしないほうが電力効率がいい、という結果が出てましたよね (弘中先生)
メモリとのデータ転送なんかもあるので、プローブを当てて測っているわけではなくて、DRP compiler が出しているのでなんとも。しかし、コンテキストをまとめた場合にどうなるか、という実験 (もちろん推測なわけだが) の結果からパラメータを導出することができなかった。
DRP は複雑だが、もっと簡単なモデルで再構成したほうが電力的に得だ、ということはあるんでしょうか? (弘中先生)
そうなるといいな、と思っていたんですが、うまくいかなかった。
速度最適、とか、電力最低、というのはあるのだが、1W あたりどのくらい、という効率の計算にしようとしたら、難しい。
[粒度可変構造論理セル向け算術演算回路の実現]
佐藤さん @ 熊本大
Hybrid cell: FA + 4bit FF = 2-LUT.
これに front logic というのをつけて、Add/sub, 2-LUT, 2-MUX として使えるようになっている。さらに、制御信号線を入力として、3-NAND, 3-AND, 3-EXOR ができる (3-OR, 3-XOR はダメ)。4 入力もできるけど、3 入力より poor.
で、これを使った各種の算術演算器を作成。
Carry Select Adder とか Parallel Prefix Adder とかも作っててかっこいい。
logic だけで interconnect が入っていないけど、アレイ型でtree いれたらやばいとか、なにか考えていることはありますか? (泉先生)
→キャリーチェーンをなるべく使いたい。
結局 RCA がよかったりする、と思うんだけど、Wallace はどう?
→キャリーチェーンはうまく使えなかった...
粒度固定の、一般的なロジックセルの場合と違う結果になったりしました (柴田先生)
→Carry Lookahead はうまくいかなかった。
最近は embedded multiplier がはやりですが
→できれば均一な構成にしたい
[スモールワールドネットワーク化配線構造の詳細遅延評価]
西岡さん @ 熊本大
short から long まで、4段階の長さの配線を持つ island-style FPGA に SWN を加える。
E 本の配線 (edge) があるときに、確率 p で pE 本の SWN wire を追加。かわりに long line を削除する (プロセスが微細化するほど long line の使用率は低下)。
VPR の PathFinder アルゴリズムをベースにして配線アルゴリズムを実装。
1. すべてのネットに対してコストが最小になる配線経路を探索
2. 競合する配線にはコストを加算
3. goto 1
SWN ラインがあると、マンハッタン距離＝最短距離とは限らなくなるので、そこの変更が必要。なるほどー。
評価は、SWN 生成確率をかえて、それぞれで 5 パターンの配置を試した。MCNC benchmark.
配線に時間がかかるって、どれくらい? (井口先生 @ jaist)
→1% の場合と 2% の場合で単純に 2 倍。SWN wire の数に線形比例。
基本的に long line のかわり? p はどれくらいにするのがよさそう? (産総研の方)
→そうですね。p のほうはまだ一概には言えない感じ。
ランダムに斜め線があるのと、規則的に斜め線があるのでは、ランダムであったほうがよいという感触はある? (森先生)
→規則的にやったほうが、遅延は削減しやすいと思うが、リソースを食い過ぎる可能性があるので、ランダムのほうがいいかなー、と思っている。
→ランダム性を持ち込んだ時点であちこちで悪さが出てくるので、もしかしたら規則的にするほうが、製造プロセスや CAD の都合もあって、そっちのほうがいい、ということもあると思う。
[SoC埋め込み型プログラマブルロジックePLX向け自動配線ツールの検討]
立命館の奥野さん。
SoC にプログラマブルロジックを埋め込むことで、少量生産品にも使えるような SoC の開発を狙う。
LUT, FF, Interconnect block が交互に並んだカラム型の構成で、こいつの配置配線手法。
Dijkstra のアルゴリズムを使って、個々の net を配線する基本ルータを作って、それを繰り返すことですべての net を配線していく。なので、配線をする順番次第で性能が左右されちゃうのだが、それは今後の課題みたい。
interconnect は階層構造みたいだ。
ePLX はアーキテクチャを絞って、配線を減らしているから SoC に適している、と考えてよい? (梶原さん)
→ ルネサスさんといっしょにやっている。フィルタ用とかプロセッサは持っているので、プロセッサでも信号処理でもない、ノリスケロジック (って、glue logic みたいなものだな)。
LUT matrix はどうつながってる? (弘中先生)
→ ひとつからは 13 箇所に直接つながっている。
なんで 2-LUT? それじゃゲート一つじゃない? (飯田先生)
→ 最初は LUT ではなくて NAND + Inverter の海だった。LUT ひとつでロジックブロックなのではなくて、ぜんぶで一つの LB みたいな感じ。
そうすると LUT 間の接続の議論もありますよね? クラスタリングとか。
→ それもまた議論しています。いまの構成で OK 、という結論がでているわけではない。
全然浮いた話じゃないですが。
恋しぐれというイネの品種が最近開発されたのだそうで、コシヒカリといくつかの品種がベース。遺伝子操作を直接やったというわけではなくて、背が高くて倒れやすいけどおいしいコシヒカリと、おいしくないけど背が低くて倒れにくいいくつかの品種の遺伝子マーカーを徹底的に調べて、うまく交配したんだそうだ。
育種っていうのは本来、何十年もかかる作業だそうなのだけれど、ゲノムが読めると簡単にできる、というのが楽しいね。
欧州じゃ Giro が盛り上がってるようですが、日本でも Tour of Japan がはじまりますよ！
今年は信州まで見に行くぜ！
修士の時に、国際会議に行った先で、POV-Ray を使って作った RDT (Recursive Diagonal Torus: JUMP-1 の結合網) の図。横から見たイメージと、上から見たイメージがあります。
階層的にマルチキャストをする様子を説明するために、1段ごとにレンダリングしたものなどを用意して使いました。ソースファイルもまだ残っていますので、必要な方はお問い合わせください。
天野研の JUMP-1 のシステム。雑然としていますが、手前が 16PE の本体で、後がわに電源ユニットが置かれています。電源の上に 3 台積み重ねてあるのは STAFF-Link のホストになる SPARCstation5 で、上に置いてある透明の箱が STAFF-Link のマザーボードです。
鈴木さん (慶應大学天野研) のスライドから、MBP-light のレイアウトの画像もいただきました。
PDC での JUMP-1 のデモの写真をいただいたので、掲載しておきます。
関係者のみなさまの肖像権に関してはお許しください...
デジタル放送のレシーバを買ったので、
たまに夜中に教育テレビとかをみてるのだが、
「高校講座」という番組をまとめて放送してたりして、
これが、いろんな科目があって、けっこう面白い。
やるな NHK!!
久しぶりに乗ったわりに調子よかった。
多摩川沿い、向かい風でガンガン抜きまくり。
調布飛行場のほうへ回って帰宅。
帰宅後、洗車して注油とか、いろいろ整備。
それから G パンがもうダメな感じなので近所の買いに行く。
裾上げしてもらおうと思って、試着の前に店員さんにお願いしたら、全然上げなくていい感じだった。試着室の前で待っててもらって、すみません。ていうか、僕は(謙遜ではなく)足が短いんだけど、こんなんで他の人は困らないのだろうか?
ヘッドライトの電池を充電したら、目潰し怪光線的な明るさが復活した。
36.29km @ 26.6km/h (1h21m40s) odo 3064.8km
あー、
チャリ乗りてぇなあ、くそー。
しかし、最近ものすごく忙しくて眠くて、
自転車乗ったら絶対事故起こす感じなので、ちょっと無理そう。
まだ働いてたさ。
寝るさ。
とりあえず今日の仕事終わった。
寝るよ。ああ、寝るとも。
Firefox のキーバインドを Emacs 風にするやつ:
http://www.mew.org/~kazu/proj/firemacs/
しろうありがと。
gcc4 を make してみた。
/usr/include がないと怒られるみたい。
% ln -s /mingw/include /usr/include
% ../gcc-4.0.4/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32
--target=mingw32 --prefix=/gcc4.0.4 --enable-threads --disable-nls --enable-lan
guages=c,c++ --disable-win32-registry --disable-shared --enable-sjls-exceptions
% make
なんてこった！連休が始まる前に連休が終わっちまったぜ！
と叫んでみる。
でもまあ、木曜と金曜はお休みだったからいいんですよ。楽しかったし。
世間は 10 連休とかだそうですがね。
仕事より楽しいことがあるうちはワーカホリックじゃない、ということなので、一安心。
ふだんの開発環境は MacPorts を使ってるのだけれど、自分の書いたプログラムをバイナリ配布するにはライブラリも配布しなきゃいけないわけだ。で、MacPorts には、個々の port を package にする機能に加えて依存関係をぜんぶまとめた meta package を作る機能もついている。
しかし、port mpkg gtk2 としたら、Xft2 のところで「もう一度インストールしてください」みたいなメッセージを出して停まってしまった。で、Xft2 の .pkg の下をチェックしたら、Contents/ の下に Archive.pax.gz と Archive.bom というファイルがなくて、他にもいくつかそういう package が存在するみたいだ。pax は tar みたいなもので、FreeBSD なんかにも付いている模様。bom はつまり、bill of materials で、要するにファイル一覧を入れておくものみたいだ。
そんなわけで、こんな script 書いてみた。
#!/bin/csh
setenv PKGDIR ${PWD}
cd /
pax -w `port contents $1 | awk '{i++; if(i!=1) print "."$1}'` > ${PKGDIR}/Archive.pax
cd ${PKGDIR}
mkdir tmp
cd tmp
cat ../Archive.pax | pax -r
mkbom . ../Archive.bom
cd ..
gzip -9 Archive.pax
rm -rf tmp
これで、
cd PACKAGE-VERSION.pkg/Contents
csh mkpackage.csh PACKAGE
とかすれば OK なはず。
あと、meta package の Contents/Info.plist に載ってる subpackage name と、Contents/Resources 以下の subpackage name が食い違っていることがある模様。要注意。
MacOS X 10.5 has autofs, but 10.4 doesn't. Alternative solution is am-utils, available in MacPorts. However, MacPorts doesn't provide any way to launch amd at startup.
In MacOS X, there's no scripts like /etc/rc, but there's launchd. I spent about a half day to launch amd by launchd and learned:
- Write the policy to launch in /System/Library/LaunchDaemons/foobar.plist
- The process spawned by foobar.plist must NOT go background, but must stay in foreground (see launchd.plist(5)!).
As the solution, I wrote a simple wrapper script (amd_start) like:
#!/bin/sh
/opt/local/sbin/amd -F /opt/local/etc/amd.conf
while [ true ]; do
sleep 360000
done
And my amd.plist is this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>amd</string>
<key>OnDemand</key>
<false/>
<key>ProgramArguments</key>
<array>
<string>/System/Library/amd_start</string>
</array>
<key>ServiceIPC</key>
<false/>
</dict>
</plist>
Put this in /System/Library/LaunchDaemons/amd.plist, then:
% sudo launchctl load /System/Library/LaunchDaemons/amd.plistThis will launch amd.
launchd is fun... It works as /etc/rc, crond and inetd. Wow.
久しぶりに乗りまくってるわけですが。
いや、最高です。
そんだけです。
Live to Ride.
Gyao で流れている、自社番組の CF に、
カメラ持ってる若者がでてるんですが、
きみ、カメラの持ち方が変だよ？
