GTCJapan雑感と、ちょっとした思い付き。
12月12日(火)～13日(水)にかけて、お台場のヒルトンホテルでGPU Technology Conference Japanが開催された。（関係者の皆様、お疲れさまでした！）
www.gputechconf.jp
当方の出番は、初日夕方の INCEPTION AI Startup Summit というスタートアップ19社のプレゼン大会と、２枚が採択されたポスターセッション。
前者は各社10分の持ち時間で自社の紹介を行うという趣向で、時間が短い事もあり、あまり欲張らずに我々の中核技術の一つ：SSD-to-GPUダイレクトSQL実行（と、今後の方向性としてSSD上のRow->Column変換）を紹介するという体裁でプレゼンテーションした。
www.slideshare.net
その結果、最優秀賞を頂いてしまった。（ｵｼﾞｻﾝﾏｼﾞﾋﾞﾋﾞﾙ）
これを日経の記者さんに取り上げて頂き、人生二度目の新聞沙汰に*1。
まだ立ち上げて半年のスタートアップに注目を頂いたり、何かの折に表彰されたりというのは大変ありがたい事ではあるが、今の段階では、まだ我々はプロダクトのリリースにすらたどり着いていない段階のひよっ子である。舞い上がることなく、着実に実行すべきすることを前に進めていきたい。
多少ぶっちゃけて言えば、審査員の皆さんは基本的にＶＣの方と聞いている。我々のプロダクトに実際にお金を払っていただけるエンドユーザ様の評価ではないという事は冷静に受け止める必要があるだろう。
もう一つ。ポスターセッションの方では、５月のサンノゼでの発表を基本的には踏襲（ベンチマーク等取り直してるが）した『PL/CUDAによる類似化合物検索』『SSD-to-GPUダイレクトSQL実行』の２テーマを投稿。前者が Top-5 Finalist に選出された。
サンノゼのGTCの作法と同様に、来場者による投票でBest Posterが選ばれるのだが、５月のリベンジで今回は Best Poster Award をいただく事ができた。
応援して頂いた皆様、ポスターをご覧頂いた皆様に、この場を借りて御礼申し上げます。
自分の出番以外には、初日の成瀬さん Volta GPU と CUDA 9 のセッションに通しで出席。
割と新しい情報がちょくちょく混ざっているので油断できない。
備忘録代わりに残しておくと、
VoltaではL2のAtomic演算が速い
これはGROUP BYのパフォーマンスに影響がでる可能性が高い。GROUP BYを実装するGpuPreAggでは、合計値やMax/Minを求めるためにグルーピングキーの値ごとに異なる場所に確保した中間結果に対してガンガンatomicAdd()を行っていくというのが基本動作だが。
もちろん、グローバルメモリへの負荷を下げるため、最大限、共有メモリ上のatomic演算を行うようにしているが、それでも溢れる場合にはグローバルメモリへのatomicを行わざるを得ないので。
もう一つはMPSの改善。PostgreSQLのようにパラレルクエリが並列プロセスによって実装されている場合、普通にCUDAを使うだけだと、ある時点でGPUを使用できるのは1プロセスだけ（時分割）になってしまうの。そのため、GPUの使用率を上げるため*2にはMPSを使って、マルチプロセスからのCUDA APIコールをプロキシする必要がある。
これは、以前のオレオレ実装GPU Serverと同じように、各クライアント間のメモリプロテクションが無かったが、Volta以降では他のプロセスが確保したメモリ領域にちょっかいが出せないようになっているらしい。
その他、Volta世代では一個のMPSインスタンスで扱えるクライアント数が16→48に増加したり、一部のSMしか使わないケース*3では複数のGPU kernelを投入できるようになったりと、かなりSQLワークロードに嬉しい改善が入っている。
思い付きネタ：意外にPCIe拡張Boxって使えるかも？
今回、展示品で見たかったモノは、ELSA Japanさんが展示されていたH3 Platform社のこの製品。
SC2017
— ELSA JAPAN (@ELSA_JAPAN) 2017年11月16日
H3 Platform
PCI Express 拡張 BOX を展示しています。GPU、NVMe のストレージ両方を搭載し SR-IOV にも対応するという欲張りな拡張 BOX です。＊ただし GPU はホットスワップや起動状態での スイッチングは出来ないとのこと。 pic.twitter.com/QXM1h2W6R3
というのも、NVMeとSSDを外部の筐体に同居できて、さらにP2P DMAが筐体内で完結するような構成になっているのであれば、ホストシステムのPCIeレーン数の上限を越えたスループットでクエリ処理が可能になるのでは？という着想があったので。
PG-StromのSSD-to-GPUダイレクトSQL実行を使うと、ストレージ（NVMe-SSD）からGPUへのデータサイズは生データそのままの大きさを転送しなければならないが、典型的なバッチ・レポーティングの処理で使われるSCAN->JOIN->GROUP BYという流れでクエリが処理される場合には、GROUP BY後のレコード数しか書き戻されない。
これはどういう事かというと、例えばテーブルから10億行くらいを読みだしたとしても、最終的にGROUP BYで1000行程度に集約されるようなタイプのワークロードであれば、大半のデータはGPUの段階で消し込まれてしまうという事になる。
で、普通のx86_64サーバのPCIeスロットにNVMe-SSDとGPUを両方搭載する場合、どうしても、電源容量、スロット数、スロット形状、スロット位置など物理的に考慮しなければならない要素が沢山ある上、CPUが直接PCIeバスを制御する場合にP2P DMAのPCIeパケットを転送する能力にも限界が見えてくる。
だが、PCIe拡張ボックス側でP2P DMAのルーティングを行い、かつ、大半のデータを消し込めるのであれば、PCIe拡張ボックス→ホストシステムへのUpLinkデータ転送能力はそれほど問題にならず、しかも、ユーザの持つデータ量に応じて段階的にハードウェアを増設できるというメリットも併せ持つことになる。
さらに、である。
データベース屋さんにとって、複数のデータベースノードを並べて互いに相矛盾しない状態を保証する分散トランザクションは、基本的に小難しい技術である。少なくとも、ノード数が１かそれ以上かというのは、データベースの運用管理上、あるいはアプリケーションの開発にとって非常に大きな違いであるが、このようにPCIe拡張ボックスを使用してソフトウェア側からはPCIeバスの延長にGPUやNVMe-SSDが見える状態にあり、かつ、SSD-to-GPUダイレクトSQL実行によってUpLinkへのデータ転送を抑制できるのであれば、分散トランザクションや傷害切り分けの小難しいあれやこれやを考える事なく大量データの処理を行う事が可能になるのではなかろうか。
もちろん、これはPCIeを直接引き延ばすソリューションだけでなく、いったんPCIeパケットをEthernetパケットに変換してリモートのI/O拡張ボックスへ飛ばすようなタイプのソリューションでも同様に適用できると思う。（なぜなら、ホスト⇔I/O拡張ボックス間の帯域はさほど問題ではないからだ）
ちなみにこの話のオチであるが、世の中のPostgreSQL関連サービス（保守サポートなど）を手がけておられる事業者の方は、多くの場合、ホストシステムのノード数やCPUコア数によってサポート費／サブスクリプション費が変わるという料金体系を取られている事が多い。
しかし、こういった形でシステムの処理能力を拡張されてしまうと、最低限の費用で従前のDWHやクラスタシステム並みの処理能力を実現できてしまう事となう。
・・・え？ヘテロDBの場合は？ウチは一応、GPU台数に比例したサブスクリプション費をチャージするという形で製品リリースを準備中でございます。（ﾌﾞｰﾌﾞｰ
