NCBI BLASTのプロファイルの取り方

NCBI BLASTのプロファイルを取らないとどこが遅いのか正確に分からないので
とってみることに

環境

CentOS
ncbi blast 2.2.24

プロファイルを取るようにコンパイル

まずソースを解凍してディレクトリに移動
実際にコンパイルするときにプロファイリングを取るようにするには

./configure --with-profiling

ってやって./configureを実行すれば良いっぽい

ちなみに
普通にソースからリリース用にコンパイルする場合は

    • without-debug --with-mt --with-build-root=ReleaseMT

を付けるらしい
参照
ftp://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/LATEST/user_manual.pdf

なにで今回は

./configure --with-profiling --without-debug --with-mt --with-build-root=ReleaseMT

でソースをコンパイルしてみる
あとはいつも通り実行してgplofでプロファイルが確認できる

Google 日本語入力でctrl spaceで半角全角の変更を出来るように変更したときのメモ

参考にしたのはここ↓
http://201.163.0.23/support/forum/p/ime/thread?tid=700ab152112a7d9e&fid=700ab152112a7d9e00049a001a1a3d57&hl

やり方

google 日本語入力のツール->プロパティ

(左から2番目のアイコン)クリックー>プロパティを選択



画像のキー設定の選択をカスタムに変更して、キー設定の選択の編集をクリック



編集を押して、とりあえず定義済みのキーマップからのインポートでお好きなものをインポート(任意)
編集を押して「新しいエントリー」を選択



4つ分新しいエントリを作り、

  • 直接入力モード → IMEを有効化
  • 入力文字なし・変換前入力中・変換中 → IMEを無効化

それぞれを画像の下4つのエントリの通りに変更
(インポートしたものによってはCtrl Spaceがバッティングしている場合があるので余計なのは消しておく)

コレでOK!

CUDAのカーネル関数がタイムアウトしてしまう場合の対処

先日購入したGeForce GTX 480を試そうとしたところ以下のようなエラーが出てきました。

Cuda error: Kernel execution failed in file 'testbed.cu' in line 367 : the launch timed out and was terminated.

原因としてはPrimary Deviceに指定されているGPUで長時間カーネル関数を実行しすぎているため。
実際に最大実行時間がどれだけかはOSによってバラバラなようでカーネル関数の実行時間が長時間の場合は注意が必要。

対処法としはそもそも長時間実行せずに細かく何度も実行するなど考えられますが、何度も実行するとさまざまなオーバーヘッドがかかるためなるべく1度に長時間実行したい場合があります。
今回の私のケースがそれで、解決したときのメモ。

XWindowを止めてしまうというのもあるようですが今回はGPUが2つあったのでこれを利用します。

環境は以下の通り。

目標はGeForce GTX 480でカーネル関数を長時間実行してもタイムアウトしないようにすること。

まず、Xorg.0.logでPrimary DeviceがどのGPUになっているかを確認します。

Primary Device is: PCI 00:02:0

上のようになっていればPCIが00:02:0のGPUがPrimary Deviceに指定されています。
あとはPCIが00:02:0がどのGPUかをXorg.0.logで確認します。

今回調べてみるとPrimary DeviceがGeForce GTX 480になっていたのでPrimary DeviceをGeForce 8800 GTにするためにGPUPCI Expressの場所を入れ替えればOK。

これでPrimary DeviceがGeForce 8800 GTになっているはず・・・
実際にカーネル関数をGeForce GTX 480で実行してもタイムアウトはしませんでした。

ただ、いちいちケースを開けるのも面倒だしもっといい方法があったら教えてください。

OctaveでLIBSVMを使う!

講義でSVMを使わないといけなくなったのでOctave上で使えるようにした時のメモ。

環境としては以下の通り。

そして今回使用したLIBSVMは以下のところから持ってきたものを使いました。
http://www.csie.ntu.edu.tw/~cjlin/cgi-bin/matlab.cgi?+http://www.csie.ntu.edu.tw/~cjlin/libsvm/matlab+zip

落としてきたLIBSVMのファイルはそのままではエラーをはいてくるのでちょこっと手を加えます。

上の3つのファイルを開いてtypedef int mwIndex;の行をコメントアウトします。
そしてOctave上でLIBSVMディレクトリに移動して以下のコマンドを打ち込む。

これでSVMが動くようになります。
試しにコードに付属しているREADMEのExamplesの一部を実行してみるために、LIBSVMディレクトリのところで以下のコマンドを打ち込む。

  • >> load heart_scale.mat
  • >> model = svmtrain(heart_scale_label, heart_scale_inst, '-c 1 -g 2');
  • >> [predict_label, accuracy, dec_values] = svmpredict(heart_scale_label, heart_scale_inst, model);

下のようなものが返ってきたらOK
Accuracy = 99.2593% (268/270) (classification)

最初からlinuxでやっていればこんな苦労なかっただろうに・・・

GPUチャレンジ2010のメモ

ちょっと前ですが5月27日にSACSIS2010に行ってGPUチャレンジ2010の自由課題に応募して優勝したときの内容を発表してきました。
GPUチャレンジについては↓
GPU Challenge 2010
あとマイコミでも取り上げられていたのでそちらもどうぞ。
NVIDIA、学生参加コンテスト「GPUチャレンジ2010」の表彰式 | パソコン | マイコミジャーナル
学生参加コンテストって書いてあるけど自由課題は助教授の人とかもokなので学生だけじゃないんですけどねw
応募した論文?は以下から見ることができますのでよろしければご覧ください。
GPUによるDNA断片配列の高速マッピング(pdf)

今回は規定課題のプログラムや自由課題のレポートはすべて公式ページにて公開されていますので興味のある方はそちらもどうぞ。

ホントはひっそりと参加してた規定課題の高速化についてあれこれ書こうと思ったけど上位チームのソースが公開されているのでやめておきます。
でも、簡単に発表で聞いてきた上位チームの高速化の要点を簡単に。

  • 計算しなければならない式の係数を式変形により削減
  • 計算した係数は使いまわす
  • 格子の端の部分の速度ベクトルを0にすることにより端の処理のif文削除
  • textureメモリの使用によるアライメントがとれていない位置の読み込みの高速化
  • .ptxを見て無駄な命令が出ないようにする
  • .cubinのバイトコードを見て同じように無駄な命令が出ないようにする(命令の種類はバイトコードからエスパーで判断したとかw)

発表では特に言ってませんでしたが他にもGPUとCPUの非同期通信やら、基本的な高速化は当然してあるそうです。

それにしてもエスパーは笑ったw

クラウドコン2010のデモツールの開発メモ

6月9日に行われたクラウドコンピューティングコンペティションにHIBIKIというチームで出場し、優勝(IBM特別賞)を頂きました。関係者のみなさま、大変お世話になりました。
公式ページは↓
クラウドコンピューティング コンペティション ・ 主催者企画 | Interop Tokyo 2010
写真がでっかくて恥ずかしいw

発表について

発表は以下のUstからどうぞ。HIBIKIの発表は37、8分のあたりからです。発表しているのはうちの代表です。

今回発表した内容についてはうちの相方がブログに書いているのでそちらを見てください。
情報科学屋さんを目指す人のメモ クラウドコン2010@InteropでチームHIBIKIがグランプリを受賞しました

デモツール

発表の様子を見ていただければわかりますが今回の発表はPowerPointではなく全て自分が作ったデモツールを使用しています。
今回は「XNA Game Studio」で開発しました。
XNA Game Studioは、「Windows」および「Xbox 360」向けのゲームを作成するための開発ツールでMSが無料で提供しているものです。
なんで、そんなものを使ったかというと最初はDirectXOpenGLなどを使おうと思っていたのですがいくつか問題が。
まず、開発に取れる時間があまりない!
作り始めたのは4月頭からなので2カ月以上あったのですが大学等の関係であまり時間が取れないことが分かっていました。このためライブラリなどが充実していてすぐに作り出せるものを探す必要がありました。
また、個人的な趣味ですが新しい言語などを覚える際に多数の小さいサンプルとそれを組み合わせた1つの大きなプログラムがあった方が勉強しやすいです。

この2つの条件を見事にクリアしてくれたのがXNA Game Studioでした。
まず、小さいサンプルは以下のところにまとまっています。

また、大きなプログラムとしては下のものを参考にしました。

↑これはちょっと慣れていないと複雑で読むのが大変ですがすごく参考になります。

XNAを使っていて苦労した点

大量の立方体の表示

デモで1つのノードを表現するのに立方体を表示しています。数個ならば普通に描画しても問題がないのですが、大量に描画しようとすると動作が重くなってしまいます。このため今回はMesh Instancing、具体的にいえばHardware Instancingを使用しています。
詳しくは↓

これによりCPUへの負荷が大幅に減らすことができ、描画がスムーズに進みます。
問題はサンプルが分かりにくいこと。ただでさえ時間がないのにHLSLまで使いだしたときには若干泣きたくなりましたw

曲線の描き方

デモではノード間の通信を表現するのに曲線で線を引いています。この曲線、簡単なようで自前でやるにはかなり面倒です。
しかし!XNAでは曲線を計算してくれるCurveクラスがありす。
実際の使い方は↓

このCurveクラスを使うことで曲線上の点の座標を簡単に計算出来ます。あとは普通にGraphicsDevice.DrawPrimitives()で線を引くだけです。簡単簡単w

最後に

あんまりデモツールを開発することはないような気がしますが、参考になれば幸いです。

次世代シーケンサーのお話を聞いてきました

5月14日にIPABセミナーで「次世代シーケンサー大量データ処理の現状」と題して発表があったので聞いてきました。
今回はその時のメモです。

Personal Genome

それぞれの人が自分のゲノムを読めるようになる
→疾患リスクの予測

生活習慣病=遺伝的背景+生活習慣

病気の遺伝的要因(SNP等以外)
→比較的広範囲でゲノムが変化している場合がある[1]

次世代シーケンサー

特徴:
1〜2週間で数億本、5TB以上のデータ(画像データ含む)が出てくる
1本あたりは数十〜100b

PacBioのシーケンサーが出てきたら従来のshort readはいらなくなる?
→エラーレートがどの程度かによってうまくマッピング等ができるかわからないので詳細待ち

現状の問題点
Linuxがうまく使えなくて解析できない
データが出てきすぎていて放置されているデータがすでに出てきている

BITSが提供している解析時に使用するマシンの構成(例)
OS:Linudx
CPU:Quad Core x2または4
メモリ:64GB~256GB
HDD 10TB~

大体500万〜(クラスターではない)

今後はより大量かつ高速なストレージが必要

データ解析の流れ

素のデータ(画像データ)
↓(1次解析)画像解析 ベースコール
配列
↓(2次解析) マッピング アセンブリ SNPコール
マッピング結果
アセンブリ
↓(3次解析)アノテーション finishing
アノテーションDB
ドラフトゲノム

シーケンサーが出すデータの大部分は画像データ(画像は圧縮などされずに生データがほとんど)

1〜2週間サイクルでTBオーダーのデータが出力される
外付けHDDに移動していることが多い

2次解析
マッピング(BWA等を使用)→並列化されやすい

アセンブリ(Velvet等)→並列化しにくい(最後にまとめるという作業があるため)

2次解析ではBWAを使うことが多い
→次の解析に持ち込みやすい形式で出力してくれるため

データ解析の本番は3次解析


シーケンサー的にはコスト面などからも十分Personal Genomeということができる時代になってきている


今回のお話でも、やっぱり一番の問題点はシーケンサーで読み取ったデータをどうやって保存しておくかが問題になっているらしい。

参考文献

[1]Ashley, E. A., Butte, A. J., Wheeler, M. T., Chen, R., Klein, T. E., Dewey, F. E., et al. (2010). Clinical assessment incorporating a personal genome. The Lancet, 375