on Shared and DistributedMemory Parallel Architectures 20121018 M2 ishizaki 文字列照合アルゴリズム AhoCorasick 法 DNA やタンパク質の配列解析 データマイニング ID: 816095
Download The PPT/PDF document "Aho-Corasick String Mataching" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Aho-Corasick String Mataching on Shared and Distributed-Memory Parallel Architectures
2012/10/18 M2
ishizaki
Slide2文字列照合アルゴリズム(Aho-Corasick法)DNA
やタンパク質の配列解析
データマイニングセキュリティシステムEtc…上記のアプリケーションは大量のデータを処理し、時間内に有意義な結果を生成するために非常に高いパフォーマンスを必要とする
背景
Slide3FPGAField-Programmable Gate Array製造後に購入者や設計者が構成を設定できる集積回路CRY XMT
超マルチスレッドスーパーコンピューターアーキテクチャ
各プロセッサが１２８スレッドを並行で動作させたり対称型/非対称型マルチプロセッサ対称型
CPU
毎の役割が同じ非対称型 CPU毎の役割が違うCell/BEソニー、東芝なとが開発した非対称型（ヘテロジニアス）マルチコアCPU
予備知識
Slide4文字列マッチングの効率的な実装に関するものFPGAを使った実装の設計Cray XMT
を用いたマルチスレッドを利用した設計
マルチコアを利用した設計Cell Broadband Engine(Cell/BE)のようなASMPを使った設計
GPU
を使った設計上記のものは主に速度に焦点を当てている関連研究
Slide5近年、検索するための入力の大きさやマッチするパターンの数から独立したようなパフォーマンスの安定性を考えられてきている。また、文字列マッチングアプリケーションは高性能だけでなく、大きな辞書に対処する能力を必要とする。
NIDS(
ネットワーク型侵入検知システム)は１００万以上の脅威を考慮しながら10Gbpsでイーサネットリンクから入力をスキャンする必要がある。
関連研究
Slide6高いパフォーマンス大きいデータセットのための統合の柔軟性カスタマイズ性
文字列マッチングに必要な特性
Slide7ハードウェアベースの文字列マッチングではメモリ不足のため大規模な辞書をサポートできないCell/BEのようなプラットフォームではプログラミングが非常に複雑でカスタマイズが困難
マルチコア、マルチスレッドアーキテクチャと
GPUの汎用計算の出現によりソフトウェアベースの文字列マッチングが高スループットの実現を可能に！！！解決策
Slide8以下の場合の最適化された実装を考える共有メモリor分散メモリ かつ
対象型、非対称型でのプロセッサーの要素
高いパフォーマンス大きいデータセットのための統合の柔軟性カスタマイズ性
入力やデータセットによるパフォーマンスの変動の制限
目的
メモリ参照の数を最小限に抑える
メモリの競合を減らす
Slide9共有メモリCray XMT(128 threads/processors)Niagara2 ×2(6 cores/processor,8 threads/core)Intel Xeon 5560 ×2(4 cores/processor,2 threads/core)
分散メモリ
対称型クラスターXeon 5560 (10nodes,2processors/node )infinibandQDRを通して相互接続非対称型クラスター
Xeon 5560,Tesla C1060 GPUs(10 nodes,2
GPUs/node)効率化する対象
※
ここでの
node
はメモリと
CPU
の一つの固まり
Slide10文字種として有効な１文字に対してそれぞれに、オートマトン(DFA)は別なノードへの遷移が存在する１文字分遷移する時、作業量は等しい
メモリを読む回数など
ACのオートマトンと入力データは読み取り専用
基礎
Slide11複数のスレッド、プロセスで実行を行う共有メモリ同じメモリ中のオートマトンにアクセスする。
分散メモリ
各々独自のオートマトンにアクセスする。ACの並列アルゴリズム
Slide12node単位へ仕事の割り当てにMPIを使用MPI(Message
Passing Interface)
とは…並列コンピューティング利用するための標準化された規格である。実装自体を指すこともある。複数のCPUが情報をバイト列からなるメッセージとして送受信することで協調動作を行えるようにする
AC
の並列アルゴリズムMPI
プロセス
node1
node2
スレッド
スレッド
スレッド
スレッド
スレッド
スレッド
Slide13入力の分割→チャンクの作成AC
の並列アルゴリズム
今日の輪講は準備が大変でした。本当に本当に疲れました。
とりあえず帰って寝たいです。
今日の輪講は準備が大変
でした。本
でした。本
当に本当に疲れ
ました。と
ました。と
りあえず帰って寝たいです。
チャンクの粒度は何スレッドで実行されるかや、辞書中の最長文字列長によって変わる
重複の非効率性＝
(
最長パターン
-1)/
チャンクの大きさ
Slide14DFAをSTTとして表す。
列＝ノード数と等しい
行＝文字種と等しい各々の列はDFAのノードを表す
セル
の最終ビットに1/0で最終遷移先かどうかを格納状態遷移表(STT)
0
1
2
3
4
5
6
0000h
0001h
0002h
0001
00…0
1
h
遷移先の先頭アドレス
1
0
0
1line = 256*256byte
=64kb
Slide15次は各々の構成毎にどのように最適化にしていくかですー。
Slide16待ち時間を減らすことに焦点を当てるCray XMTの場合メモリアクセス時間の変動の主な原因は
ホットスポット
にある頻繁に同時に複数のスレッドがアクセスするメモリ領域の事原因アルファベットなどの特定の文字のメモリ部分の読み出しのアクセスが増えるため。
深さが浅いノードでのアクセスが大半なため。
Cray XMTの実装
0001h
Slide17Alphabet shuffing256中でアルファベットが連続しているのが問題なので、線形変換を用いいてシャッフルする。
Symbol’=(symbol ×
fixed_offset) >> 8State replicationノードの浅い部分のSTTのレプリカを作成する。
同じ
STT列の異なるレプリカのアドレスはランダムにその状態を指す。CRY XMTでの解決策
Slide18各CUGAスレッドは独立して入力テキストのチャンクでマッチングを実行する。これは、各スレッドの高い使用率を維持しながら適度なサイズのチャンクを使用する。
STT
の違い遷移先はアドレスでなく索引で保持するテーブルの各セルは32bitもっていて31bitが遷移先の索引で、最後の
1bit
を終端フラグとする。GPUでの実装
1line = 256*32bit = 1kb
Slide19問題点1(ホットスポットが発生する可能性あり)各メモリコントローラーは256
バイト幅メモリパーティションを管理していて、一つのメモリコントローラーに作業が集中する可能性（
partition camping）Tesla C 1060の場合8つのパーティションがあるため、
32bit
の256個のセル(ASCII)の合計1024byteの行だった場合、１つのメモリコントローラーで２ノード分管理している
特定の偏りのある入力によってアクセス部分を集中してしまう。
GPU
での実装
Slide20解決策共有メモリ上のSTT行のうち、よくアクセスされるSTT
行
(ノードの深さが浅い部分)をテクスチャメモリに移動GPUでの実装
Slide21問題点２単一のソースからデータをストリーミングするアプリケーションでは、入力テキストを順次ホストメモリにバッファリングする。
そこで、入力を１文字づつ
読み込む際にスレッドはチャンクのひとまたぎづつロードしなくてはならない
GPU
での実装
Slide22解決策グローバルメモリに入力テキストをコピーした後に変換を適用する。入力テクストは４文字毎(32byte)
毎にグループ化され、読み込みはグループ毎に行う。
GPUでの実装
Slide23三種類の構成1.MPI&シングルスレッド2.MPI&
マルチスレッド
3.MPI&GPUMPIのロードバランサはバッファとバッファサイズの背一定可能なマルチバッファ方式を採用マッチ数が多いほど多くのキャッシュミスが生じて速度を低下させるので、動的に仕事を割り振った方が効率が良い
分散メモリでの実装
Slide24MPI&マルチスレッドの例分散メモリでの実装
MPI
node1
node2
node3
afjdsafjsafjsklfajskdfajsfk
afjdsafi
fisafisk
sklfaisk
スレッド１
スレッド
2
スレッド１
スレッド
2
スレッド１
スレッド
2
afjds
dsafi
fisaf
afisk
sklfa
faisk
Next→sklfaisk
Slide25文字列照合の速度をGbpsで比較辞書語
Dictionary1
19万パターン、平均１６バイトのテキストDictionary219万パターン、平均１６バイトのテキストとバイナリデータEnglish
２万パターン、平均
8.5バイトの一般的な言葉Random５万パターン、平均８バイトのランダムアルファベット文字列実験
Slide26Input dataTextEnglish text of the King James BibleTCPTCP/IP traffic
Random
ランダムアルファベット文字列Itself辞書にマッチする単語をつなげたもの実験
Slide27使用マシンNiagara 2Two Niagara 2 processors (1,165GHz) 32GB of memoryXMT
128 node, with a total of 1 TB of memory, Seaster2 interconnection
X86 SMPTwo Xeon 5560 processors(2.8GHz), 24GB of memoryX86 cluster10 nodes, each one configured as the x86 SMP, interconnected with Infiniband QDR (24Gps)GPU cluster
10 nodes with two Tesla C 1060 (4GB of memory) each.
実験
Slide28入力テキストは単一のソースからストリームされ、処理される前にメモリにバッファされている。入力に使用するバッファサイズは１００MB
入力をチャンク化させた時のサイズは２
KBスレッドの利用数の点でのトレードオフだが、経験的に決めた値非効率性は最悪の場合で0.7%(16byteの時)
重複
の非効率性＝(最長パターン-1)/チャンクの大きさ実験
Slide29どの時もわりとLinearに近い結果となっている
結果
(Cray XMT)
Slide3048を越えたあたりで、ホットスポットの影響をやや受け始める
結果
(Cray XMT)
Slide31X86…8 threads/processor
結果
(x86 SMP)
Slide32Nehalem内のキャッシュ構造が原因でスレッドを増やした時にたまにパフォーマンスが落ちる。キャッシュ内の存在しないメモリにアクセスする確率が高くなる
itself
などはパフォーマンスが落ちる結果(x86 SMP)
Slide33Niagara2では80スレッドまでは高速化するが、96
で限界がくる
結果(Niagara 2)
Slide34Itselfが遅くなる理由はキャッシュの問題
結果
(Niagara 2)
Slide35GPU(tesla),Niagara2,Xeonはマッチングが少なかったり、辞書が小さいとパフォーマンスが大きいSTT
をキャッシングするのにテクスチャメモリが足りないのが原因
評価(各々の共有メモリプラットフォームの性能のばらつき)
Slide36１ノードにつき2つのMPIプロセスを実行している
1
ノードにつき最大12threads動かせる？？Intel Xeon 5560 (4 cores/processor,2 threads/core
)
(10nodes,2processors/node)評価(x86 cluster)
Slide37評価(x86 cluster)
ボトルネックは
5ノード
原因は
infinibandの帯域制限ノードが増えすぎるとMPIの方でも多く帯域を使うので性能が落ちたりもする
Slide38評価(CPU cluster)
Slide39共有メモリ構成での並列処理分散メモリ構成でのMPIロードバランサを使用した並列処理
まとめ