2015年04月16日

OSS版Siri - Siriusのペーパーを読む(その2)

昨日に引き続き、Siriのペーパーを読んでます。

Sirius: An Open End-to-End Voice and Vision Personal Assistant and Its Implications for Future Warehouse Scale Computers

昨日のおさらいとして、Siriusの行う処理はトラディショナルなWebサーチと比べると100倍以上負荷がかかるものであり、今後もこれらのサービスの利用はどんどん増えていくことが想定されるので、もっと効率よくしないとね、というような話でした。

今回はそこからボトルネックを見つけ出し最適化させる話。

ペーパーではGPUやFPGAなどを使わない状態で、シングルスレッドで動かしてSiriusの各工程のどこで処理能力が使われているかを確認しています。細かい点は本文のFigure8〜10あたりに書かれています。

ASR(automatic speech recognition = 音声認識)、QAIMG(画像検索)の3点に分けた場合、QAが最も負荷が大きく、処理時間の揺れも大きいという結果になっています。

各工程ごとの処理時間についても分析しています。

ASRではGMM(Gaussian Mixture Model = ガウス混合モデル)もしくはDNN(deep neural network)で大半の処理時間を使っています。

QAではstemming(複数形とか過去形を揃えたりするようなヤツ)と正規表現CRF(Conditional random fields。MeCabとかでも使われてるヤツ)の3つで85%の処理時間を使っています。判定の部分よりもベーシックなテキスト処理の方が効いているようです。stemmerとかは検索エンジンでも動いてませんでしたっけ。

画像認識ではfeature extraction(特徴抽出)とSURF(Speeded Up Robust Features。イメージの角度とかが変わっても一致できるヤツ)に大半の処理時間を使っています。

これを確認した上で、本気を出す時間がやって参りました。下記の製品を利用してリトライです。(価格は本文のTable6より)

  • Intel Xeon E3-1240 V3
    4コア。250ドル。
  • NVIDIA GTX 770
    GPU。399ドル。
  • Intel Xeon Phi 5110P
    60コア240スレッド! 2437ドル。
  • Xilinx Virtex-6 ML605
    FPGA。1795ドル。

マルチコアCPUでは例えば画像の特徴抽出であればいくつかのタイルに分けて個別に処理し、最後に同期させます。この方法だとSURFは改善が難しかったとか。

instead of parallelizing at a smaller granularity within the SURF algorithm, which would require multiple synchronizations between loops

しかしSURFについては並列処理による効果は薄かった。ループ内で複数回の同期が必要になってしまうので。

Phiでも似たようなアプローチになる為、その性能を十分に活かせたとは言い難いコードになっているそうです。

the results represent what can be accomplished with minimal programmer effort.

今回の結果は最低限の並列処理を活かす為の努力をしたものになります。

各処理が60コアを活かせるようなアルゴリズムを持っていれば良いのですが、なかなかそれは現実的ではない。

GPUではCUDAを使っています。文字列処理についてもGPUで処理ができるように独自に開発したそうです。

FPGAはGMMとStemmer用の独自の実装を用意したそうです。具体的には……よくわからなかったので本文の4.3.4とFigure11とFigure12を見てください。(読むの疲れた)

日本語ではStemmerを使う機会は少ないので(その代わりわかち書き的な処理が入ると思われます)、日本語に対して最適化しようとするとまた他の実装が必要になりそうです。

結果として、パフォーマンスは下記のようになりました。

ServiceBenchmarkCMPGPUPhiFPGA
ASRGMM3.570.01.1169.0
DNN6.054.711.2110.5
QAStemmer4.06.25.630.0
Regex3.948.01.1168.2
CRF3.73.84.77.5
IMMFE5.210.52.534.6
FD5.9120.512.775.5

前述にもあったように、残念ながらPhiの性能はまったく活かされない結果に終わっています。1リクエストの並列処理ではなく、並列で送られてくるリクエストをそれぞれ別プロセスでさばくベンチならまた違うと思われます。

FPGAが全体的に良い結果を出しています。CPUをそれ用に特化させたわけなので、そりゃ速いですよね。GPUもコストと手間の割にはかなり良いスピードを出しています。

この後、電力効率やコスト対効果などがまとめられていますが、その辺は今後のハードウェアの動向ですぐに変わってしまいそうな気がするので割愛します。

FPGAの利用は個人でできるレベルの話ではないので、私のような末端の開発者としてはGPUを使うべき場所できっちり使うことが重要だと思われます。

posted by newsit at 07:00| machine_learning