readとwriteでプロセスIDが違うでやんの。これじゃ＜ピー＞※と組み合わせて使えないじゃないか！
というわけで、少しいじったけど放置プレイに格下げ。
あぁ、あと＜ピー＞※でコンパイルしたら動作が腐りました。やっぱ駄目だ。
※まだネタをばらしたくないので伏字
続：CUDAのメモリ操作には何かが足りない
そうか、symbolを使えばconstantメモリにデータを格納できるのか。symbol系の転送命令ならちゃんとoffsetあるわ。
CUDAのメモリ操作には何かが足りない
オフセット指定が無い。
つまり、GPU上に大きなメモリを確保した場合は、それを送受信する際にCPU側にも同じサイズのメモリを確保する必要がある、と。
……何か間違ってないか？
よくよく考えてみると、OpenGLやDirectXでGPUとデータをやりとりする場合はテクスチャを確保して適当にデータを送受信していた。ここではオフセット調整ができた。CUDAにもテクスチャがあるので関数リファレンスを参照してみると、オフセットの調整が出来そうに見える。なるほど、こっちを使えばいいのか。
ここまで読んだところで、CUDAにはLocalMemory,SharedMemory,GlobalMemory,ConstantMemory,TextureMemoryという多数のメモリが存在しているわけだが、どれが何メガ使えるのかを把握していなかったことに気がついた。うーむ、まだまだだな。
glDeleteFramebuffersEXTで（ｒｙ
データサイズ間違えてた。そりゃセグメントエラーもするわな。orz
USBメモリにLinuxをぶち込んで持ち歩こう（途中）
一週間くらい試行錯誤してることの中間報告。
基本的にやりたいことは、VMとしても直接でもブートできるLinux環境を持ち歩けるようにしたいということ。USBメモリから直接起動できるLinuxは実験をするときなど何かと便利だけど、作業PCが１台しかないときは使っているPCを落とさなくてはならない。じゃあVMからも起動できればいいよね。
更に応用的な要求が２つ。１つは、USBメモリにWindowsから書き込める領域を残したいということ。純粋にデータ共有という意味でも便利だし、もしかしたらWindowsからLinux用に設定ファイルを渡せたりしないかしら、とか。もう１つは、RH系のLinuxが使いたいということ。これは単純に私がGPUプログラムなどをいじるときに都合が良いからである。ついでにいってしまえばUSBメモリからコピーインストールができれば完璧なんだけど、これは難しいよなあ。
VMはとりあえずqemuを使う方向。何故ならば、Windowsからインストールなしで使えるから。ついでに言えば、qemuで物理ドライブを参照する方法がわかったから。
というわけで、参考資料２つ。
QEMUで物理ドライブを使う方法とOpenSUSEをUSBメモリに入れる方法。
qemuでは-hda //./PhysicalDrive0とか-hda //./PhysicalDrive1とかを使うことで物理ドライブを仮想ディスクど同様に利用できる模様。これはWindowsからどう認識できているかとは直接関係がないらしい。WindowsからUSBメモリを使う場合、先頭のパーティションしかマウントできないという制限がある。しかしながらこの方法では２つ目のパーティションにOS（というかブート領域）があっても利用可能。
OpenSUSEの公式（英語・日本語両方）にUSBメモリへのインストールの資料があったので利用。
というわけで実験。
USBメモリをパーティション分割し、先頭パーティションにFAT領域を作成、第２パーティションにext3の領域を作成。第２パーティションにOpenSUSEをインストール。インストールCDから再度起動して途中のオプションからUSBメモリ上のLinuxを起動。grub-installでUSBメモリにgrubを導入。一度終了してCD-ROMを撤去。起動。ブート順序を変更しUSBから起動。場合によってはUSB-HDDじゃなくてUSB-ZIPあたりに認識されるかもしれないのでてきとーに。grubのパラメタはデフォルトで正しい保証なし。root(hd0,1)をroot(hd1,1)に変更とか、適当な値を指定してがんばって起動。また、Windowsを起動してqemuからの起動も確認。qemu.exe -L . -hda //./PhysicalDrive1とかで。こっちもgrubが合わない可能性が高いので注意。特に、ドライブがhdaとして認識されるのでsdaでは駄目。おそらくhda。/dev/hda1をマウントすることでWindowsとLinux(VM)で同じHDDを参照することも可能。書き換え反映のタイミングが怪しい。
とまぁ、大体こんな感じで起動は確認できます。以下、現時点で問題点が２つ。
１つめは、ハードウェア変更の差にどこまで対応できるか不明であること。少なくともVMで起動を試みた時点でXの設定が違ってこけると思います。ネットワークも然り。この辺は入れるLinuxの特性にもよるかもしれません。knoppixやその他LiveCDなんかは環境の変更に強いはずなので、LiveCD+差分データってのを考えたほうがいいのかもしれません。ちなみに、手元のPCの１台はgrubからLinuxを立ち上げるものすごく早い段階で躓きました。起動時のパラメタを練らないと駄目かもしれません。これは実行する環境によってはgrubから与えるパラメタをなんとかして把握しないといけないことを意味するので割と致命的です。
２つめは、BIOSか何かの都合でUSBメモリの第２パーティションをうまく認識できないかもしれないこと。手元のPCの１台が、先頭パーティションのLinuxは起動できても第２パーティションのLinuxが起動できないという問題に陥っています。起動できないというか、grubにたどり着けないというか。
さて、現在こんな感じです。割と動いていますが、実行環境への柔軟な対応という意味ではやはりLiveCD系を活用したほうが良い気がしています。実は、小さいUSBハブにUSBメモリを２つ挿し、片方をLiveCD起動用（isolinux系はisoから展開して格納しても起動可能にできます）、もう一方をデータ用とかするのが最強かもなぁとか思っていたりもします。うーむ。
余談ですが、GParted LiveCDというのを使うとUSBメモリのパーティション変更とか楽チンです。まさかパーティション変更用のLinuxLiveCDなんてあるとは思わなかったよ。
これから研究を始める後輩たちへ
書こうと思ってなかなか書けてなかったものを書いてみる。ちょっと長いよ。
私は仮にも博士後期課程の学生なので、卒業研究と修士研究が終わっていますし、今では博士研究をやっているわけで、まぁ初めて研究をやろうとしている学部生の参考になることくらいは書けるんじゃないかなあと。
ただ、ぐだぐだと書いても誰も読まないので極力簡潔に。あと、分野的にかなり限られた話しか書けないのは仕様。
とりあえず、卒業研究は参加賞です。修士研究は努力賞です。博士研究は知りません。
「卒業研究は参加賞」とは言っても、「とにかく参加すれば良い」ってだけのことではありません。「参加して研究とは何であるか、どう進めるものであるか」を学ぶものです。多くの場合、卒業研究が初めの研究であり、その手順などを全く知りません。恐らく、文献調査を行い、問題を発見し、解決方法を提案し、実装なり調査なり何なりを行って結果をまとめるという行為をした経験が全く無い人が大半です。（分野が違うとこのプロセスを踏まないわけで、そこまではサポートできませんごめんなさい。）
卒業研究ではこれらを身をもって体験し、経験値を得ることが何よりも重要です。もちろん素晴らしい研究成果が得られればそれにこしたことはありませんが、それはあまり考えなくても良いと思います。就職するにしても進学するにしても。それから、研究の大部分が車輪の再発明になっちゃってもいいと思います。本当に全てが車輪の再発明で終わっちゃうと流石に困るんですが。オープンソースで開発されているものをやっちゃうと流石にどうしようもないけど、ぶっちゃけ企業が製品化していて内部実装非公開のものなら車輪の再発明でも研究の意味を主張できると思うよ。っつーか、価値がわからなくならないようにサポートするのも指導陣の役割だよね。
ただ、問題はこのプロセスを学習できないケースが少なくはないらしいということです。つまり、卒業研究の課題が先生から与えられちゃう研究室があるらしいということです。自分がこのケースに当てはまらなかったので驚いたのですが、どうやら一部の研究室は自分で問題を探すというプロセスをやらせないらしいんですよね。これは良くない。オートマトンの生成という意味では正しすぎるんだけど。
このような研究室になっちゃった人は、卒研を問題解決能力を鍛える場だと割り切り、それはそれとして問題発見能力の修行をしたほうが良いです。
いずれにせよ、問題発見能力の修行なんてのは誰でも持っているに越したことはないので鍛えたほうがいいです。ニュースでもblogでも何でも情報を入手し、それについて何かを考えるようにするだけで少しはマシになります。多分。自分がどの程度マシかを知らんのでこれ以上は言えんのですが。
さて。
修士研究は、卒業研究の経験を活かしてがんばる場です。だから努力賞。ただまあ何か新しい知見が得られないとしょんぼりなので、頑張らないといけません。卒論の経験を活かして頑張れ。
では新しい知見を得るためにはどうするべきか。要するに研究テーマを決めるためにはどうすればいいか。
ぶっちゃけると定石はあります。論文誌の掲載論文を読んで、今後の課題として挙がっているものをぱくれば一丁あがりです。ただし、当然ながらこれは公開問題なので誰かがもうやっているかもしれません。っつーか、執筆者が既に取り組んでいるかもしれません。その場合は内容理解の時間の都合で勝率が下がります。先に出したら勝ちなのは事実。そこで、論文誌掲載論文の前提条件をよく読んでみることにします。よくあることですが、多くの研究では何らかの制限・絞込みをしています。議論を簡単にするため、いきなり大風呂敷を広げて発散しちゃうのを防ぐため、とにかく対象問題に何らかの絞込みをしていることが多いので、絞込みから溢れた範囲に目をつけましょう。
逆に（？）、そもそもある特定の問題を解くために行われた研究を、全く別の問題に持ち込むのもありです。この場合は「別の問題」が本来の問題から離れていてかつ自分の得意分野であるととても有利になります。当然ですね。要するに足し算的な考え方をすれば、テーマを探すのは簡単です。簡単なので、誰でも思いつくかもしれないのが大変なんですが。
他の手法として思いつくのは、例えば過去の研究で否定されていたものを敢えて持ち出すなんてのもありかも知れません。当時は技術や流行の都合で利用しにくかったけど、今なら使える、なんて技術はありませんか？ わかりやすい例で言えば、Ajaxで見直されたJavaScript。2000年くらいのころはうぜえ重い邪魔だブラクラだと忌み嫌われたJavaScriptも、今では必須技術に格上げされています。
まぁわかりやすいところではこんなところでしょうか。
書いてみて思ったけど、これは参考にならんな（ぁ
っつーわけで、後は余談。
0から1を産み出すのは大変です。大変だからこそ凄いし素晴らしい。でも、個人的には1から2も同じくらい素晴らしいと思う。唯一だと思っていたものが実は２つあった、みたいな感じです。多分5くらいまでは凄い。でもそれ以上はどうでもいい。ところが、これが1000とかになるとそれはそれで凄い。まぁ実際のところは工場製手工業が工場製機械工業になったという裏事情によるもので、機械化という新しいことが凄くてその影響を見ているだけかもしれませんが。
ほら、こぴぺであるじゃん、
ドイツ人が発明し、アメリカ人が製品化し、イギリス人が投資し、フランス人がデザインし、イタリア人が宣伝し、日本人が小型高性能化する
ってのが。みんな凄いと思うんだ。その先は自粛。
Icecast2とices0でストリーミング再生
色々試行錯誤した結果落ち着いたのがこの組み合わせ。
ウチのFreeBSD鯖には片っ端から手持ちの音楽CDをMP3化してぶち込んであるので、それなりにたくさんのMP3ファイルが置いてあるのですよ。で、家でも大学でもどこでも適当に聞けるようにストリーミング再生をすることにしたのです。
ただちょっと変態なのは、好きな曲……というかハイテンションのベストセレクションストリーミング再生もやりたかったのでプレイリストをどうやって作ろうかが問題になったことかしらん？
というわけでてっとりばやく環境構築のメモを。
- /usr/ports/audio/icecast2
- /usr/ports/audio/ices0
の二つをぶちこむ。
/etc/rc.confに
icecast_enable=”YES”
ices0_enable=”YES”
を書いておく。
/usr/local/etc/icecast.xmlを適当にいじって（ポート番号とパスワードあたり）
# /usr/local/etc/rc.d/icecast2 startでストリーミング鯖起動。
ices0でストリーミング鯖に音楽を投げつけ、視聴者は鯖を経由してices0の音楽を聴く。しかしices0を普通に(# /usr/local/etc/rc.d/ices0 start)動かすと複数のプレイリストが使えない。
つーわけで、起動方法を変えて、
# ices0 -c configfile -B
を使う。
- c は設定ファイルを指定するフラグなので、configfileには/usr/local/etc/ices0.conf のカスタマイズコピーを指定。-Bはバックグラウンド実行のフラグ。configfileの中でTypeとModuleの指定をするとスクリプトファイルが使える。今回はTypeにperlを指定してperlスクリプトを使うことにした。
/usr/local/etc/modulesにices.pm.distが入っているはずなので、これを”Moduleで指定した名前.pm”にして使う。
ここで使うスクリプトだが、おそらく、最低限ices_get_nextさえ書けば動くだろう。私の場合はこの関数内で適当なプレイリストファイルを開いてランダムに１行取得するという処理を書いた。毎回プレイリストを開きなおしているので、他のプロセスからプレイリストへ曲を追加する処理を書くことでお気に入りプレイリストを更新するのも自由。
ices_get_metadata関数も埋めてやれば、再生中の曲などを表示することができる。グローバル変数を使って解決してみた。
ices_initは初期関数。私は乱数の初期化しかしていない。
ices_shutdownは終了処理だけど今回は何もしていない。ices_get_linenoはcueファイル関連らしいので放置。
ベストセレクションの作成はこのプレイリスト読み込みを利用して実現。apacheから見える別のページに現在ランダムプレイリストで再生中の曲を表示し、ボタンを押すとそれがセレクションプレイリストに追加されるという仕掛けを作った。今のところ特に何の問題もなく機能中。便利。
まあこんなところかしら。
メモリースティック転送速度の罠
先日、PSPに動画をぶちこんでいて気が付いた。メモリースティックの転送速度はモノによって結構大きな差がある。
っつーか、ぶっちゃけると手持ちのメモリースティックへの書き込みが異常に遅かったので、買い足した。
どのくらい差があったかというと、
実験１：20MB程度のファイルを書き込んでみた
実験素体１(Lexar製 MEMORY STICK PRO DUO 1GB)：
20MB/50sec = 409 KByte/sec = 3276k bps
実験素体２(SanDisk製 SanDisk ultra II 2.0GB)：
20MB/9sec = 2275 KByte/sec = 18204k bps
実験２：HDBENCHを動かしてみた
実験素体１：
ALL Read Write RRead RWrite Drive
2270 6883 3732 6501 1043 G:\100MB
実験素体２：
ALL Read Write RRead RWrite Drive
3068 7628 6934 7256 2728 G:\100MB
このくらい。
差、ありすぎだろ。っつーかLexar遅すぎだろ。相性でも悪いのかしら。
っつーわけで、PSPで遊ぶ人はメモリースティックにも注意したほうがいいよ！というお話でした。
[weblog]ついに出た！ 32GBの大容量SDメモリカード : Gizmodo Japan（ギズモード・ジャパン）
ついに出た！ 32GBの大容量SDメモリカード : Gizmodo Japan（ギズモード・ジャパン）
SDカードヤバイ。マジヤバイ。32GB。手元のX40が40GBモデル。もうノートPCのHDDこれでいいよ。速度と耐久性能知らんけど。
[weblog]玄人志向、PCI Express x16－x1変換基板など“キワモノ”変換基板4製品 - ITmedia +D PC USER
玄人志向、PCI Express x16－x1変換基板など“キワモノ”変換基板4製品 - ITmedia +D PC USER
x1をx16に刺すのか？なんだそりゃ……
と思ったら逆だった。ちゃんと動くのかなこれ。ビデオカードが転送速度落ちてでも動けば、それはそれで面白いかもしれない。まぁ、転送速度が遅いGPUがどんだけ価値があるかは……。