私は Nvidia Cuda について読んでいて、「あなたの問題は GPU で実行するのには適していません」というコメントが含まれている場所で人々が答えた SO に関するいくつかの質問を見てきました。
私のオフィスには、膨大な数のレコードを含むデータベースがあり、クエリを実行するのに永遠にかかる可能性があります。SELECT DISTINCT または値に対して大文字関数を適用する SQL クエリを実装しました。Cuda の紹介として、GPU ですべての文字列を大文字に変換できるプログラムを作成することを考えました。
PCIバスを介したデータの読み取りまたはグローバルメモリへの配置のレイテンシを隠すために、GPUコアを可能な限り実行しようとすることについて著者が話しているCudaに関する本を読んでいます。メモリ サイズが非常に小さく、何百万もの異なる単語があるため、当然、バスが飽和状態になり、GPU コアが枯渇します。
これは、CPU ではなくグラフィックス カードから素晴らしいパフォーマンスの向上を受けられない問題ですか?
ありがとう、
mj
操作/転送比が O(1) であるため、グローバル メモリ アクセスにかなり大きなボトルネックが発生します。
おそらくもっと価値があるのは、GPU で比較を行うことです。これは、操作/転送比がはるかに大きいためです。
これを行うために文字列を共有メモリにロードする際に、それを大文字にすることもできます。これにより、以前にやりたかったことなどを効果的に含めることができます。
CPU ベースの実装の方がおそらくパフォーマンスが向上するだろうと思わずにはいられません。少なくとも、頭痛が少なくなるでしょう...
SELECT DISTINCT または値に対して大文字関数を適用する SQL クエリを実装しました。
事前に計算された文字列の大文字バージョンを使用してテーブルに列を追加することを検討しましたか?
データベースが完全に RAM にあり、クエリがまだ「永久に」かかる場合、データベースが適切に構造化され、インデックス化されていない可能性があると思います。クエリ プランを調べます。
通常の場合、選択がインデックスできちんとカバーされている場合、GPU で最適化することはできないと思います。ただし、ワイルドカードを使用した LIKE クエリなどのテーブル スキャンを必要とするクエリや、計算に基づいて行を選択するクエリ (値がより小さいなど) など、GPU 用に最適化できるものがあるかもしれません。結合列に多くの重複値がある場合、多くの結合を持つクエリのようなものでさえあります。
このような実装の鍵は、データベース内の一部のデータのミラーを GPU に保持し、それをデータベースと同期させることです。次に、そのデータに対して並列リダクションなどの操作を実行して行 ID を取得し、通常のデータベースに対する選択に使用します。
ただし、そのような手順を実行する前に、時空間のトレードオフを使用するデータベース クエリの最適化の無数の可能性を探ります。