2008年12月31日水曜日

USB Devices in VMware Server on Ubuntu

以前は普通に使えたと思うんだけど、気づいたらUSBデバイスがGuest OSから見えなくなっていました。あれれ?と思って調べてみたら、この辺が原因らしい。

#2のコメントの通り、mountdevusbfs.sh のコメントを外してあげて、fstabにusbfsの項目を追加。最後に

% sudo mount usbfs

で見えるようになりました。

とりあえず/proc/bus/usbの問題かどうか切り分けるには、usbviewを使うと良いかも。

% sudo apt-get install usbview
% usbview

これでデバイス一覧が表示できれば問題なし。上記の設定をしない状態(usbfsがmountされていない状態)だと、/proc/bus/usbの設定を見直せ、みたいなエラーメッセージが出てきます。

2008年12月24日水曜日

LilyPond


楽譜を書かせるソフトは色々あるけど、綺麗に表示させようとすると物凄く面倒。DTMソフトにも曲データをそのまま譜面で表示する機能はあるけど、表示を気にしだすと曲を作ってるんだが楽譜を作ってるんだか、わからなくなりがち。

ってことで、CUI慣れしている私にお似合いなツールがこれ、LilyPond。要するに楽譜入力のためのTeXフロントエンドだと思って間違いない。MMLライクに音符を入力していき、

% lilypond lovelymagic.ly

などとコマンドを叩くと、lovelymagic.psとlovelymagic.pdfを吐き出してくれる。MML慣れしている自分にとっては、とっても便利。難点を列挙すると、
  • 繰り返しを綺麗に書こうとすると構造的に書く必要があり直感的ではなくなる(TeXで数式を書く時の感覚に近い)
  • オクターブの考え方がいわゆるMMLの系譜とは違って、常に直前の音から4度以内が「オクターブ指定なしの音程」となる。例えばMML的な「a<c」は単純に「ac」でok。逆にMML的な「gc」は「gc'」と書く必要がある。
ちなみに右の画像がLilyPondで書いてみたサンプル。エンディング部分が書いてないけど、某曲のドラム譜です。PNGで出力する事もできるんで、そのまま出力をアップロードしてみました。

T'SoundSystemにもコンパイラから.lyを吐き出して、LilyPond経由で楽譜PDFを生成する機能を付けよっかなぁ。

2008年10月4日土曜日

Cluster OpenMP

分散メモリ環境で共有メモリ型の並列プログラムを実現する環境としてIntelのCluster OpenMPって機能があるようです。その名の通り、PCクラスタなどの環境でOpenMPによるプログラムが可能となります。Intel Compiler v9.1以降でサポートされているようですが、完全にOpenMP互換というわけではなく、共有する変数にsharable指示子を付ける、などの移植作業は必要なようです。Intel以外の会社の出しているベンチマークを見ると、あまり性能良さそうではないのですが。。。Relaxed Consistency Modelを採用しているようです。Google File SystemもやはりRelaxed Consistency Modelですね。やはり分散環境でそれなりの性能でCoherenceをとろうとしたらRelaxedしかないのかな。
Clustern OpenMPのsharable heapがどのような実装になっているのか調べてませんが、SVM的な事をやってるんでしょう。SVMに関しては、コンパイラの介入を許す場合、コンパイル時に共有メモリアクセスを検出して、前後に特殊な命令列を挟む、などとしてfalse sharing missを減らすようにする工夫があるみたいです。とりあえず滝田さんの論文を見る限り、Shasta(*1)やBlizzard-S(*2)という研究があったようです。どちらも1996年ですね。
共有メモリだがCoherence制御はハードウェアでは行わない。コヒーレンスをとりたい場合はatomic指示をしてTransactional Memory的な制御をする、みたいな方向で新しい並列モデル、作れませんかね。いや、共有メモリって部分はなくした方が良いのかなぁ・・・不正なプログラムの挙動を保証できなくなって、潜在的なバグを作り込みやすい環境になっちゃうし。

*1: A Low Overhead, Software-Only Approarch for Supporting Fine-Grain Shared Memory
*2: Parallel Computer Research in the Wisconsin Wind Tunnel Project

2008年9月28日日曜日

共有とか分散とか

メニーコア化が進むと、いずれキャッシュコヒーレンス制御が難しくなってくる。
BlueGeneにはじまる超並列計算機環境が既にそうであるように、近いコアとは共有メモリ、遠いコアとは分散メモリ、といった環境にならざるを得ない。こういった環境でプログラムしようとすると、プログラマは共有メモリと分散メモリ、OpenMPとMPIといったように、2つの層を意識した複雑なプログラム開発を強いられる。これは大変、という事でもっともナイーブな解決策は、共有メモリであっても一貫してMPIを使うという方法。この方式だと共有メモリが利用できたとしても、MPIを通して、高速に通信可能な分散ノードとしてしか見ない。けどまぁ、どのみち外側の分散メモリ環境が並列計算全体を律速するので、よほど物理的なノード構成、ネットワークトポロジを意識して最適化しない限り、これでほとんど問題はない。というか、MPIを使っている時点で、そこまで繊細なチューニングはできない。
ただ、一般的な用途を考えた場合、SMPですらマルチコアが一般に浸透するまでこれだけ時間がかかったのだから、メニーコア環境をMPIで使いこなすエンドユーザ環境というのはあまり想像できない。となると、やはり今後の流れとしては、ハードウェアで一部のコア群のコヒーレンス制御を行い、コア群間のコヒーレンス制御は必要に応じてソフトウェアで行うことになるのかなぁ・・・。そうするとShared Virtual Memoryが再び脚光を浴びるようになる気がしないでもない。たぶんOSレベルで機能を取り入れるべきで、OSの仮想記憶管理と統合しちゃう。んでまぁ、コンシステンシモデルはどうするかと言えば、Transactional Memoryと統合しちゃって。TMの世界が主流になれば、そもそも細切れにコヒーレンス制御を行う必要はなく、Transaction単位でメモリの同期を行えば済むようになる。あとはデッドロックをどう考えるか、なのかなぁ。

2008年9月17日水曜日

ハードウェアプリフェッチ

ハードウェアプリフェッチの分析方法としてSrinivasanらによるPTMT: Prefetch Traffic and Miss Taxonomy(*1)という手法が有名です。古典的な評価では、Coverage(本来ミスだったメモリアクセスの何割がプリフェッチで救えたか)とAccuracy(プリフェッチのうち何割が有効なプリフェッチだったか)でしか評価してなかったわけですが、PTMTではプリフェッチを行った場合と行わなかった場合の両方のケースについて同時にシミュレーションを行い、プリフェッチにより取得したキャッシュライン、プリフェッチにより追い出されたキャッシュラインそれぞれがキャッシュヒットとなったか、あるいは追い出されたかを調べて分析します。例えばあるプリフェッチにより取得したキャッシュラインがヒットしたとしても、追い出したキャッシュラインがミスを引き起こしてしまっては意味がないわけです。

これがマルチプロセッサ(SMP)環境になると、キャッシュのコヒーレンス制御が影響してきます。プリフェッチにより早期にデータを取得しても、その後のリモートプロセッサのストアによりせっかく取得したキャッシュラインをINVALID化する必要があります。このような効果も考慮したのがJergerらによるMPTMTと呼ばれる手法(*2)です。

さらにマルチコア(CMP)の場合にどうなるかというと、これはちょっと複雑で、キャッシュを共有する効果ってのも考える必要が出てきます。SMPの時のようなコヒーレンス制御の影響より、アグレッシブなプリフェッチを行った際の汚染の影響の方がクリティカルになるので、CMPならではの新しい問題、というよりはシングルコアの頃に研究されていたキャッシュのAccuracyを高めるといった手法が効果的になってくるみたいですね。そんなわけで、プリフェッチをフィルタリングして最小限度の質の高いプリフェッチを発行する、というのがプリフェッチ研究の1つの柱としてあるようです。プリフェッチのターゲットアドレス、あるいはプリフェッチを発行したPCをキーとしてプリフェッチが有効だったか否かのヒストリーをとり、そこから先は分岐予測と同じストーリー。やっぱりgshareとか使うと良い結果が出たりします(*3)。学習が入ってくるとなると、学習の種としてPTMT的な分析手法も重要になってきます。実際にインプリできるハードとして、1回の実行でどれだけ効果的に学習できるか、ですね。ちょっと前にキャッシュのセット方向の情報を使って1回の実行で様々なキャッシュサイズを想定したミス率変化グラフを書くって手法を聞きました。なんか同様のうまい方法を思いつかないかなぁ・・・なんて考えてたりしますが、一朝一夕にはいきません。

整数系のベンチマークでは、RDS: Recursive Data Structuresに着目した研究成果(*4)もあります。リストとかを辿る処理を検出して先読みする類いのやつです。この手の構造体のポインタを読み出すLoad命令をIPL: Induction Pointer Loadと呼ぶらしいです。なんか、アーキテクチャ屋さんにとっては紛らわしい略語ですね。この手の研究は学生の頃にもちょろっと調べた記憶があります。Sohi先生のとこでもやってたような。こっち方向の研究はあまり筋がよくない事が多いですよね。

*1: A Prefetch Taxonomy
*2: Friendly Fire: Understanding the Effects of Multiprocessor Prefetches
*3: Reducing Cache Pollution via Dynamic Data Prefetch Filtering
*4: Characterization of Repeating data Access Patterns in Integer Benchmarks

2008年9月14日日曜日

POWER6の物理設計

あまり新しい話題でもないですが、IBM Journal of Research and DevelopmentにてPOWER6の特集が組まれていまして。その中でも気になっているのがIBM POWER6 microprocessor physical design and design methodologyって記事です。

図2に設計フローが紹介されているんですが、これによればPOWER6はVHDLで論理設計を行っているんですね。今までゲートレベルで設計していたプロセッサメーカも徐々にRTL設定にシフトしてるって事でしょうか。

面白いのが、RTLへ移行したタイミングで周波数が一気に上がって、でも複雑なOoO制御は止めて・・・という、直感とは違う結果が出ていること。後者は電力から来る要求で、そもそもアーキテクチャをダイナミックに変更できたというのがRTLの成果なのかもしれませんが。周波数に関しては、ゲートレベル設計が有利というのはもはやアセンブラプログラムが速いってのと同様の幻想なのかもしれません。

System z10の特集はまだだけど、同じような傾向があるのでやっぱりRTL設計なのかな。

気迫と勘だけで作ってる某社とは違って、きちんとサイエンスしてるな、と思います。

追記:設計フローの基本はPOWER4の頃から変わってないとの事で、POWER4の特集を調べたら当時からVHDLで論理設計をしているようでした。ただ、物理設計周りの人手でやっていた部分がだいぶ自動化されたようですね。