関東GPGPU勉強会資料

2,358 views

Published on

関東GPGPU勉強会(2012-06-02)の資料です。

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,358
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
10
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

関東GPGPU勉強会資料

  1. 1. GPGPUこの3年でどう変わったか 関東GPGPU勉強会 2012/6/2 日本ユニシス株式会社 加藤公一
  2. 2. 自己紹介加藤公一(かとうきみかず)• Twitter: @hamukazu• 所属:日本ユニシス株式会社• IEICE システム数理と応用研究会専門委員• GPGPU参戦:2008年• 社内ではNVIDIAの回しものと言われている
  3. 3. NVIDIA GTC• NVIDIA主催のGPGPUのお祭り• 私は2009年に講演• 今年(2012年)は聴衆として参加
  4. 4. 今日の話• 自分の研究の紹介• GTC 2009と2012を比べて何が変わったか?
  5. 5. GTC2009での私の講演• You Might Also Like: A Multi-GPU Recommendation System• GPUでリコメンデーションシステムを作り ましょう、という話
  6. 6. 全体の処理の流れ Singular Value Decomposition K-Nearest NeighborK. Kato and T. Hosino. Multi-GPU algorithm for k-nearest neighbor problem. Concurrency and Computation:Practice and Experience, 23, 2011.K.Kato and T.Hosino, Singular Value Decomposition for Collaborative Filtering on a GPU, IOP Conference Series:Materials Science and Engineering 10 012017, 2010.K.Kato and T.Hosino, Solving k-Nearest Neighbor Problem on Multiple Graphics Processors, In Proc. CCGrid2010,Melbourne, Australia, pp 769-773, 2010.
  7. 7. k-Nearest Neighbor Algorithm The algorithm consists of two parts: Computation of distances and k-partial sort
  8. 8. N-Body Algorithm [Nyland et al. 2008] Block 0 Block 1 Block 2 Because of limited size of shared memoryNyland et al. “Fast N-Body Simulation with CUDA”, in GPU Gems III, pp 677—695, 2008
  9. 9. High dimensional case“Slice” the dimension so that the data can be loaded in a shared memory Block 0 Block 1 Block 2
  10. 10. 部分ソート(上位k個ソート) アルゴリズム• GTC2009当時は、かなりトリッキーなアル ゴリズムで速度を出していました• しかしFermiで試すと、かなり事情が変 わっていた – 挿入ソートだけでかなりいけた• 実はこのネタでGTC2012も出そうと思って たのだが断念
  11. 11. Bench mark (kNN)Hellinger distance n 10000 20000 40000 80000 1x GTX280 (a) 2.7 8.6 34.1 131.8 2x GTX280 (b) 1.8 5.7 17.7 68.6 Core i7 (c) 354.2 1419.0 5680.7 22756.9 (c)/(a) 131.1 173.3 166.5 172.6 (c)/(b) 196.7 248.9 320.9 331.7Euclidian distance n 10000 20000 40000 80000 1x GTX280 (a) 2.6 8.2 32.1 124.8 2x GTX280 (b) 1.7 5.5 16.9 65.2 Core i7 (c) 124.8 503.0 2010.0 8041.4 (c)/(a) 48.0 61.3 62.6 64.4 (c)/(b) 73.4 91,4 118.9 123.3 d=256, k=100
  12. 12. そしてGTC2012Efficient k-NN Search Algorithms on GPUsNikos Sismanis, Nikos Pitsianis, Xiaobai SunBitonic sortが最速では、という話
  13. 13. 部分ソート、実は深い!• kとnの値で最適アルゴリズムが変わる• さらにGPUの特性によって変わる• Keplerでまたさらに考え直し?• 考えるのは大変だけど楽しい• でもこれだけで一生を終えたくない
  14. 14. その他何が変わったか• 開発環境が劇的に変化(改善)• C言語がJavaになったような感じ(たとえ が悪い?)
  15. 15. 2009年当時のデバッグ環境• エミュレータのみ• エミュレータで再現しないバグが最悪
  16. 16. エミュレータで再現しないバグの対 処法 (当時)• 怪しいところで、メモリのスナップ ショットをグローバルメモリの別領域に (手動で)コピー• カーネル関数終了後、スナップショット をdevice to hostコピー• それを見て不具合を見つける
  17. 17. ワイルドだろぉ
  18. 18. GTC2009 Developer Round Table(だったっ け?)• コンパイラは信用できない• 思ったパフォーマンスが出ないときは、 まずコンパイラを疑う• 普通は、アセンブラ(ptxファイル)を見 て確認する
  19. 19. そして今は・・・• NVCC優秀• CUDA-GDB, CUDA-MEMCHECK• ProfilerのEclispeプラグイン• Nsightとか• OpenACC、CAPS HMPP
  20. 20. まとめ• 3年の間に目覚ましい進歩 – 次の3年はどうなるか• 最適アルゴリズムも進歩に合わせて変化• 革新的な技術に初期のころから手をつけ ると苦労が大きい – その分メリットも

×