gstore_fdw: GPUメモリをSQLで読み書き、そして…。 - KaiGaiの俺メモ
昨年、PGconf.ASIAで発表したPL/CUDAによる創薬ワークロードの高速化実験のテーマであるが、 kaigai.hatenablog.com 実測したベンチマークを見ると、奇妙な傾向が見てとれる。 このワークロードにおける計算量は「Qの行数×Dの行数」であるので、Dの行数が同じ1000万行であるならば、Qの行数が1000のケース（22.6s）に比べ、Qの行数が10のケース（13.4s）の実行時間はもっと顕著に短時間でなければならない。 計算量が1/100なのに、実行時間は半分弱にしかなっていない。 実はこれは、化合物同志の類似度を計算するための時間だけでなく、PL/CUDA関数に与える引数をセットアップするための時間に12秒程度を要しており、アムダールの法則を引用するまでもなく、類似度の計算を高速化するだけでは処理速度はこれ以上伸びないのである。 PL/CUDA関数の引数として行列
カスタムロジックをWHERE句で使う - KaiGaiの俺メモ
しばらくSSD-to-GPUダイレクトSQL実行の開発にどっぷり時間を突っ込んでいたので、久々にPL/CUDAネタ。 この辺のネタや、 kaigai.hatenablog.com この辺のネタで kaigai.hatenablog.com 紹介したように、PG-Stromはユーザ定義関数をCUDA Cで記述するための機能（PL/CUDA）を持っており、これを使えば、データベースから読み出したデータをGPUに流し込み、GPU上でカスタムのロジックを実行した後、結果をまたSQLの世界へ戻すという事ができる。 この仕組みはPostgreSQLの手続き言語ハンドラの機能を用いて実装されており、ユーザ定義のPL/CUDA関数が呼び出される毎に、手続き言語ハンドラが以下の処理を行う。 ユーザ記述のCUDA Cコードブロックをテンプレートに埋め込んで、ビルド可能なソースコードを作成。 NVRTC(NVI
進捗）SSD-to-GPU ダイレクトSQL実行機能 - KaiGaiの俺メモ
ここ暫くブログでまとめていなかった、SSD-to-GPUダイレクトSQL実行機能の進捗について。 この機能をかいつまんで言うと、NVMe-SSDに格納されているPostgreSQLのデータブロックをGPU RAMに直接転送し、そこでSQLのWHERE句/JOIN/GROUP BYを実行することで見かけ上のI/O量を削減するという代物である。 NVIDIAのTesla/Quadro GPUが対応するGPUDirect RDMA機能を使い、SSD<=>GPU間のデータ転送を仲介するLinux kernel moduleを使えば、CPU/RAMにデータをロードする前にGPU上での処理を行うことができる。 しばらく前からScan系の処理には対応していたが、JOIN/GROUP BYへの対応を加え、さらにPostgreSQL v9.6のCPU並列にも追従したということで、簡単なベンチマークなら取れる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
