一方，こちらでは5月の半ばに春学期が終わります．大学生だけなく，小学生も高校生も同様で，これから長い休みに入ります．子供がずっと家にいるので，お母さんは大変ですね．ただし，この長い夏休みの間に，思い思いのサマーキャンプなどに参加しているようです．私のお世話になっているUniversity of Tennessee (UT)のキャンパスでも，なんだかわからないイベントをたくさんやっていますし，陸上，バスケットボール，チアリーディングとサマーキャンプが開催されているようで，普段は見慣れない人で溢れています．
日本では3月のGGFに続いて，CCGRIDというGridとClusterの国際会議が東京で開催されました．私も参加するべくポスターセッションに投稿したのですが，いろいろな先生にお世話になったにもかかわらず，直前で，アメリカへの再入国の際に必要なビザがなかなか取得できないなどの理由によって泣く泣く日本への帰国を断念しました．また，この時期，アジアでは重症急性呼吸器症候群（ＳＡＲＳ）がはやっていたこともあって，会議への参加を取りやめた人も多かったようです．主催された方々は非常にご苦労されたのではないでしょうか．研究室からもインド出身の博士課程の学生が発表する予定だったのですが，日本国というのは，インドの方に冷たいのですね．彼は日本で発表することを楽しみにしていたのですが，インドの方の日本への入国はビザが必要で，日本での国際会議に採録されているにもかかわらず，その手続きは非常に煩雑で，タイミングが悪く，日本国の要求する資料がどうしても一つそろわなかったために，会議への参加を断念しました．もちろん，日本へ来られる外国人の方が良い人ばかりであるとはいいませんが，このようなことで，優秀でかつ，日本に興味がある技術者・研究者が来日できないのは非常に残念なことです．
さて，今回は，ICLの目玉プロジェクトのPAPIとComuter Scienceに所属するICLとは兄弟研究室にあたるLoCI Labの開発するIBPについて簡単にご説明しましょう．
Performance API (PAPI)はInnovative Computing Lab (ICL)の開発しているCPUのハードウエアカウンタにアクセスするためのライブラリです．
ハードウエアカウンタとはなんでしょうか．
最近の汎用CPUでは，ほとんどの場合，データキャッシュミス数などの情報がハードウエアカウンタとしてカウントされているのだそうです．よって，この情報を利用できれば，どのような計算を行ったのか，どのようにキャッシュミスなどが発生しているのかを知ることができます．しかしながら，もちろんこのハードウエアカウンタへのアクセス方法は，CPUによって違うわけです．よって，通常であれば，このCPUへのアクセス方法を探して，そのCPU独自のAPIを利用しなければなりません．これはあまりに不便です．すべてのCPUに対して統一的なAPIがあって，簡便にハードウエアカウンタへアクセスできれば非常に便利です．それを行ってくれるのが，PAPIなのです．
PAPIでは我々が接する汎用のCPUであれば，ほぼすべてサポートしています．例えば，Linuxであれば，PAPIが用意しているカーネルのパッチをあてて，カーネルを再構築することによって利用することになります．
PAPIでは，High Level InterfaceとLow Level Interfaceの2種類があります．High Level Interfaceでは，flopsをカウントすることと，イベントのカウントを開始してそのカウント数を知らせることしかできません． しかしながら，イベントには，各レベルのキャッシュのヒット，ミスヒットなどをカウントできたり，細かい命令がいくつ行われたかをカウントできるので，非常に多くのことができるようになっています．（イベントの説明のページ）
下記の図はPAPIのページからの引用ですが，時間ごとにFlopsを表示して，アプリケーションの動作を調べている図です．
キャッシュミスの状態と照らし合わせると，Flops数が出ていないところでは，キャッシュミスが起こっていることがわかります．開発ユーザーはこの情報をもとに，キャッシュミスをおこさないプログラムにチューンアップすればよいわけです．
PAPIではPerfometerとよばれるJAVAのGUIを提供しています．これを利用することで視覚的に処理の概略がわかります．上記の図はPerfometerの結果を模擬したものです．
PAPIはバージョンは最新のものではないですが，Windowsもサポートしています．インストラクションに従ってインストールすると，PAPIがインストールされます．この中かから，PAPI Shellを利用しましょう．いくつかの簡単な例題があるので，Flops数の計測は簡単にできます．ただし，P4やAthronへの対応は次期バージョンからであること，計測とPerfometerの利用を別々に行うことは可能なのですが，同時に行うと不都合が生じることなどの問題があります．Linuxマシンでハードウエアカウンタを利用し，WindowsでPerfometerを利用することには何の問題もありません．
このように，プログラムのチューンアップを行うためには，PAPIは非常に便利なツールで，いろいろなところで利用されている業界ではほぼデファクトスタンダードな製品です．
ちなみに，中心開発者の一人はPhilip J. Mucciですが，現在，ノックスビルから離れてサンフランシスコで開発を進めています．Jack DongarraはこれをICL West Officeと言っています．
Logistical Computing and Internetworking (LoCI) LaboratoryはMicah Beck 教授の主催する研究室で主に分散ファイルシステムを開発しています．ここで開発されているシステムもなかなか面白いので簡単にご紹介しましょう．
上記の図は，分散ファイルシステムの分類を，メタデータとデータそのものがどこに存在しているかを表している図です．通常のHDDには，ローカルサイトにHDDにメタデータもデータそのものもあるわけです．クラスタシステムなどで使われている並列ファイルシステムは，メタデータもデータもそれぞれ分散したレポジトリに置かれていることが多いでしょう．
それに対して，Internet Backplane Protocol (IBP) は，データはリモートに存在していますが，メタデータはローカルに存在するのです．簡単に言えば，FTPなどではリモートのファイルの探索はリモートで行わなければなりませんが，メタデータがローカルに存在するIBPでは，ファイルの探索はローカルで行うわけです．
これを分散環境に適応させるための仕組みが，eXnodeとL-Bone，Logistical Runtime System (LoRS)です．
LoRSは1つのファイルを複数コピーし，任意のスレッド数に分割して，IBPの分散レポジトリに保存します．その再に，eXnodeを作成して，どのスレッドがどこに保存しておくかを記録しておくわけです．UNIXのinodeのようなものですね．eXnodeはxmlで記述されています．そして，分散されたIBPのディレクトリ状態を管理するのが，L-Boneです．LDAPを利用して，各分散レポジトリ情報を管理しているのです．
LoCIで管理されているレポジトリは世界各国に分散していて，下記の図の赤い点のように存在しています．
LoRSを使うと，指定したコピー数分だけ近くのサイトにスレッドを別々にコピーします．ダウンロードするときも，一番近いところからダウンロードしてくるのです．
IBPは小さなファイルを頻繁にやりとりするというよりも，比較的大きなファイルをアップロードしたりダウンロードしたりするのに向いています．IBPのデモでよくおこなわれているのですが，映画のような動画サイズが適しています．IBPのアプリケーションの一つにIBPvoというのがあります．これは予約した時間に指定されたテレビがIBPを利用して録画され，録画後，メールでeXnodeが送られてきて，それを利用してダウンロードして利用するという仕組みです．各レポジトリノードではデータは暗号化されていますが，メタデータが，各ユーザのローカルなサイトにあるわけですから，このように著作権が問題となるような場合には便利なツールです．
今回はPAPIとIBPをご紹介しました．世の中には，いろいろと重要だったりおもしろかったりするプロジェクトが多く存在します．我々はそれらのプロジェクトやツールをどのように知り，利用していけばよいでしょうか．
特に日本のプロジェクトは，やはりこちらで暮らしていると，アメリカやヨーロッパからはあまり見向きをされていないことを実感します．同時に，日本から海外へ向けて情報発信を躊躇している面も多々あります．情報発信をして，できるだけ，コラボレーションを行いながら，プロジェクトを展開していく．難しいことです．