スキャン速度10GB/sへの挑戦～その④ 完結編～ - KaiGaiの俺メモ
今回のエントリは、ここ１年ほど取り組んでいた PG-Strom による大量データのスキャン・集計処理性能改善の取り組みが、当面の目標であったシングルノード10GB/sを達成したという完結編です。（長かった） 要素技術：SSD-to-GPUダイレクトSQL 先ず、PG-Stromのストレージ関連機能について軽くおさらい。 RDBMSに限らず一般論として、GPUなど並列プロセッサの処理性能を稼ぐには、プロセッサコアの数や動作クロック以上に、処理すべきデータをできるだけ大量に供給するかという点が重要。 これは、ハードウェアレベルではキャッシュ階層や容量の設計、あるいはメモリデバイスのデータ転送レートという話になり、最近のGPUだとメモリ読出しの帯域は数百GB/sにも達する。もう少し大局的に見ると、これは、ストレージと計算機をどのように接続し、アプリケーションはこれをどのように制御するのかという話
NECを退職し、新会社を立ち上げました。 - KaiGaiの俺メモ
ご報告が遅れましたが、6月30日付で新卒の2003年から14年あまり勤務したNECを退職しました。 また、本日、東京法務局品川出張所においてヘテロDB株式会社の登記申請を行い、また、併せて新会社のチーフアーキテクト兼代表取締役社長に就任しました。 今後は、前職では実現できなかった、GPUやSSDなどヘテロジニアスな計算機資源を活用する事で、高性能、低価格、使いやすさを両立するデータベース製品の事業化を目指していく事になります。 どうぞよろしくお願いいたします。 web: http://heterodb.com/ 弊社が入居する西大井創業支援センター（品川区） 10年以上も勤務した会社を辞めてスタートアップを立ち上げるというのは、おそらく人生の中でも上位に食い込むビッグイベントの一つだと思うので、今の決意や創業に至る一連の流れについて記録を残しておこうと思います。 （書き下してみたら意外と長
GTC2017 - 個人的トピック - KaiGaiの俺メモ
個人的トピックまとめ。 ポスター発表 今回、急遽渡米することを決めた理由がこのポスター発表。 セッションやトレーニングと並行して、GTCではGPUを用いた研究開発ネタのポスター展示が行われており、今年は約140件のポスター展示が採択されている。 このうち、プログラム委員の評価が高い20件が、S7480 - Fast Forward Poster Program for the Top 20 Posters のセッションで各々4minづつの発表を行う。さらに Top-20 の中からプログラム委員が事前に選定した5件が "Top-5 Poster Finalist" という扱いで、コンベンションセンターの正面、最も目立つ場所に掲載され、参加者がモバイルアプリ経由でどのポスターが気に入ったかを投票する。 最も票を集めたポスターには GTC2017 Poster Winner Award と副賞$
進捗）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並列にも追従したということで、簡単なベンチマークなら取れる
PCIeスロット接続型NVMe-SSDまとめ（2017年4月時点） - KaiGaiの俺メモ
PCIeスロット接続型のNVMe-SSDのスペック等、各社どうだったけな～と探すものの、案外まとまった情報がないので自分でまとめてみた。ブックマーク代わりです。 基本的に各社のWebに掲載されているカタログスペックを転記。手作業なので内容の正確さに関しては保証しかねます。（指摘頂ければ直します） Intel社 コンシューマ向け モデル Intel SSD 750 400GB(MLC) Intel SSD 750 800GB(MLC) Intel SSD 750 1.2TB(MLC) 形状 HHHL HHHL HHHL PCIe PCIe 3.0 x4 PCIe 3.0 x4 PCIe 3.0 x4 容量 400GB 800GB 1.2TB SeqRead 2100MB/s 2100MB/s 2400MB/s SeqWrite 800MB/s 800MB/s 1200MB/s RandRea
2017年の開発ロードマップについて考える - KaiGaiの俺メモ
あけましておめでとうございました。（やや出遅れ感） 新年という事で、この一年、どういった技術開発に取り組んでいきたいかをざーっと書き出してみる事にする。 これらのうち、いくつかはPostgreSQL本体機能の強化を伴うものであったりするので、ある程度計画的にモノゴトを進めないといけないワケで…。 PG-Strom v2.0 先ず最優先で取り組むのが、PostgreSQL v9.6への対応。 CPUパラレル実行と、新しいオプティマイザへの対応でかなり大きなアーキテクチャ上の変更を伴ったものの、全体としてはよりシンプルな設計に落とし込む事ができている。 ちなみに、現状だとこの程度までは動くようになっている。 集約演算がGroupAggregateとGpuPreAggの二段階に分解されており、GpuPreAggはGatherの配下で並列に動作している事に注目。 postgres=# EXPLAI
動いた！SSD-to-GPU Direct DMA - KaiGaiの俺メモ
ここしばらく、NVMe-SSDからGPUへとPeer-to-Peer DMAを行うためのLinux kernelドライバを書いている。 これは昨年末のPGconf.JPのLTでアイデアを先に発表したもので、従来は、例えばテーブルスキャンに際して90%の行がフィルタリングされる場合であっても、データをストレージからRAMにロードしていた。しかし、どうせフィルタリングするのであれば、バッファのために利用したRAMのうち90%は無駄である。 基本的なアイデアは、ストレージからのデータロードに際して、CPU側のRAMではなく、GPU側のRAMへロードし、そこで数百～数千コアの計算能力を使って行のフィルタリングや、あるいは、テーブル同士のJOINや集約演算を行ってしまう。そして、これらの前処理が終わった段階でCPU側へデータを書き戻してやれば、CPUから見ると『ストレージからデータを読出したら、既に
エルザ・ジャパン様の対応が神レベルだった件 - KaiGaiの俺メモ
雑文です。 現在取り組んでいる SSD-to-GPU ダイレクト機能の実装には、PostgreSQL/PG-Strom側の機能拡張だけれなく、NVMe SSDからGPU RAMへのDMAを実行する Linux kernel ドライバの開発が必要になる。 Linux kernelにはDMAを実行するためのインフラが既に多数揃っているので、ドライバの開発自体はそれほど大仕事ではないのだが、GPUがその機能に対応している必要がある。 NVIDIA提供のドキュメントによると、 GPUDirect RDMA :: CUDA Toolkit Documentation GPUDirect RDMA is available on both Tesla and Quadro GPUs. と、あり、いわゆるコンシューマ向け廉価製品であるGTXでは対応していない。 対応していないというのは、GPU上のRAM
SSD-to-GPU Peer-to-Peer DMAとバッファ管理（その１） - KaiGaiの俺メモ
昨年の暮れ、JPUGカンファレンスのLTで『SQL+GPU+SSD=∞』と題したスピーチを行った。 SQL+GPU+SSD=∞ (Japanese) from Kohei KaiGai www.slideshare.net これはかいつまんで言えば、ストレージからデータをCPU+RAMへとロードするより前に一旦GPUへとデータを転送し、そこで不要なデータを削ぎ落してからCPU+RAMへと渡してやる事で、CPU負荷の軽減とRAMの有効活用が計れるというアイデアである。 実装としては、PCI-Eデバイス間でのP2P DMA機能を利用する事によってNVMe SSDの特定ブロックからGPU RAM上の特定の領域へDMAを実行するというものなので、ここは別に新しくも何ともない。 以下の図は、従来の仕組みにおけるデータの流れを示したもの。 SSDから読み出されたデータは先ずCPU+RAMにバッファされ
PostgreSQLのデータ構造はなぜ並列プロセッサ向きではないか。 - KaiGaiの俺メモ
今年もPostgreSQL Advent Calendar 2015に参加しています。 前からちょくちょく『PG-StromってXeon Phiだとどーなんですか？』的な質問を受ける事があんですが、データ構造から見て難しいので『勘弁！』という理由を紹介してみたいと思います。 PostgreSQLのレコードは、内部的には HeapTupleHeader 構造体を先頭とする可変長データとして表現されています。 struct HeapTupleHeaderData { union { HeapTupleFields t_heap; /* MVCC関連情報 */ DatumTupleFields t_datum; /* xmin, xmaxとか... */ } t_choice; /* current TID of this or newer tuple */ ItemPointerData t_
OpenCLでCPU/GPUを使い分ける？ - KaiGaiの俺メモ
最近、PG-Stromに興味があるという方からちょくちょく、個別に質問メールを頂く事がある。 その中で頂いたコメントに興味深い洞察が。 GPUによるアクセラレーションは確かに興味深い機能だけれども、PG-Stromの本質は突き詰めていえばパイプライン処理のお化けだよね？だから、計算処理をCPUでやるようにしても良いんじゃない？ 確かに。GPUによる並列処理はハマると物凄い費用対効果をもらたすけれども、例えば正規表現マッチみたく、GPU向きじゃない処理もある。 PG-Stromの場合、SQLのWHERE句に与えられた条件から行を評価する関数を自動的に生成、それをJITコンパイルして実行する。たぶん、プランナの時点でCPU実行用、GPU実行用の２種類の関数を自動的に生成して、計算サーバに渡すという処理は実現可能だろう。 NVidiaのGPUを前提とするCUDAと異なり、OpenCLはAMDのG
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
