6/26 (木)
台北 國立故宮博物院展@上野 東京国立博物館
24日から上野の東京国立博物館で台北 國立故宮博物院展がはじまったので観てきた。 名称問題で揉めて中止になるのではと危惧されたが、予定通り開催されたようだ。
会期は9月15日までだが、「翠玉白菜」だけは2週間のみ7月7日までの公開になっている。 本展は平成館の2階で開催されているが、翠玉白菜は会場を分けて本館で展示。 14時に翠玉白菜の列は180分待ちになっていたので、諦めて本展を観に行く。 こちらはほとんど並ばずに入れた。
台北の故宮博物院の展示物は紫禁城にあったものを日中戦争期に移動したもの。 紫禁城のものは2012年に北京故宮博物院200選(2012年1月28日の日記)として来ている。 今回の展示では明・清代のものが多かった。
16時頃に本展を見終わった後は、翠玉白菜の列は120分待ちになっていた。 腹の調子もおかしいので、白菜は諦めて帰る。
6/24 (火)
[時事] 地震と雹
アラスカ西部の現地時間23日午前11時53分(日本時間24日午前5時53分)に M8.0 の地震が発生。
そして日本では調布付近に雹が降り、7センチ程度積もるという事態に。 6月も終わりだというのに大変だ。
6/21 (土)
[Movie] 超高速!参勤交代
『超高速!参勤交代』を観たが、割と噴飯ものの脚本だった。 そもそも「参勤交代」で国元に帰ったところを呼びつける場合、華美な行列は不要だろう。 護衛だけでさっさとくればよいのではという疑問がぬぐえない。
6/20 (金)
[Movie] 300 帝国の進撃
チネチッタで『300 帝国の進撃』(現題 300 Rise of an Empire)を観て来た。 前作があったことは知っていたが、これは三部作の二部目のようだ。
紀元前449年にギリシアとアケメネス朝ペルシアの戦争を題材にしているが多分にファンタジーで見所もいまいちだったよ。
6/14 (土)
6/11 (水)
6/10 (火)
6/7 (土)
[Movie] 劇場版 ペルソナ3 #2 Midsummer Knight's Dream
チネチッタで 劇場版ペルソナ3 の第2章を観る。 第1章の時は、これが連作だと気づかなかった。
川崎ではチネチッタしか上映していないようでかなりの混みようだ。 いつもなら空席の前方のブロックに座ったのに、前左右に客が入っていた。 後方ブロックはほぼ満席だったようだ。
[Movie] ポンペイ
ついでに『ポンペイ』を観てきた。 正直、火山が噴火するという以外は、ポンペイである必要がない映画だったあるよ。
今日見つけた怪獣酒場
よく行くタイ料理店のチャオタイの隣に怪獣酒場という特徴的な店が出現した。 老若男女と問わない長い行列ができていたよ。
6/4 (水)
InfiniBand の Extended Reliable Connected (XRC) の仕様を読む
pib での実装を前提に Supplement to InfiniBand Architecture Specification, Volume 1.2.1, Annex A14: Extended Reliable Connected (XRC) Transport Service (Mar 2009, Revision 1.0) を読む。 この仕様書は Specification Download のフォームに入力するとダウンロードできる(フォームに入力するがアカウントを作っているわけではないので次回も入力が必要)。
1 つのノードに複数のプログラムが動作している場合、InfiniBand の Reliable Connection(RC) を使うと Queue Pair(QP) の消費量が多くなる。 システム内のノード数を N、ノード内にあるプログラム数を p とすると、プログラム間をフルメッシュでつなぐためには N * p * p 個の QP が必要になる。 昨今のメモリ NUMA や I/O NUMA の関係で、最適化のために 1 つのシステム内にある NUMA ノードごとにプログラムを立ち上げる必要がでてきた。 また 1 つの CPU コアを細かく制御するために、コア毎にプログラムを立ち上げたりもする。 つまり p が大きくなる。 しかし必要な QP 数は p が二乗で増えるので、これは不味い。
Extended Reliable Connected(XRC) は RC とほぼ同機能の InfiniBand サービスだが、必要な QP 数を大幅に減らしてくる。 XRC はメッセージの送信側の XRC INI QP と受信側の XRC TGT QP を完全に分離するが、この 2 種類の QP をプロセス間で共有できる点がミソだ。 そのため前の条件で言うと XRC INI QP は N * p、XRC TGT QP も N * p になる。 p が 1 なら 2 倍必要なのだが、 それ以上なら RC を使うより XRC を使う方が QP 数が節約できる。
XRC INI/TGT QP はプロセス間で共有した場合、プロセスの識別は XRC SRQ で行う。 XRC SRQ はこれまでの SRQ を拡張している。 これまでの SRQ が Receive Queue だけを持っていたのに対して、XRC SRQ は Receive CQ を持ち Send CQ と Receive CQ の指定できる。 XRC SRQ はプロセス毎に存在し、同一の XRC INI/TGT QP に対して異なる XRC SRQ がつながることになる。
その上で送信側プロセスは XRC INI QP を使い、送信先プロセスを示す通信先ノードの LID、XRC TGT QP の QP 番号、XRC SRQ 番号の 3 つのパラメータを指定してメッセージを送信する。 XRC TGT QP は受信したメッセージを XRC SRQ にディスパッチするので、目的のプロセスにメッセージが到着することになる。
対比項目 | RC | XRC |
---|---|---|
Send Queue | RC QP にある | XRC INI QP にある |
Send CQ | RC QP からつながっている | XRC SRQ からつながっている |
Receive Queue | SRQ にある | XRC SRQ にある |
Receive CQ | RC QP からつながっている | XRC SRQ からつながっている |
ただし XRC INI QP と XRC TGT QP の間に存在するコネクションは 1 本だけである。 そのため XRC INI QP と XRC TGT QP 間のコミュニケーション確立は、ノード内のプロセスが調整して代表のプロセスが行う必要がある。 また結局 XRC INI/TGT QP はステートが一つしかないので、XRC INI/TGT QP が Error ステートに落ちると、全てのプロセスからその経路は通信不能になる。
Annex A14: XRC Transport Service の仕様には未定義な部分が残っている。 XRC QP に対する非同期イベントや非同期エラーがどのプロセスに上がるのかなどが決められていない。