これはテストすることができると私は知っていますが、私は理論に興味があります。CUDAルックアップテーブル対アルゴリズム
私は、理論的に高速で、共有メモリのテーブルからのランダムなルックアップ（バンクの競合が可能）と、 'n' fpの乗算によるアルゴリズムとの比較を試みています。
ベスト・シナリオのシナリオは、共有メモリのルックアップにバンク・コンフリクトがないため、20〜40クロック・サイクル、最悪の場合32バンク・コンフリクトと640〜1280クロック・サイクルです。乗算は命令ごとに 'n'サイクルになります。これは適切な推論ですか？
fp乗算に1サイクルかかるのですか？ 5サイクル？どの時点で、いくつかの乗算として、共有メモリルックアップテーブルを使用するのが理にかなっていますか？
命令ごとの乗算はnサイクルになります。これは適切な推論ですか？ 'n' fpの乗算を行うとき、コアはそれらの操作でビジー状態を維持しています。おそらく単なる「マルチ」命令ではなく、「mov」のようなものもあります。だから多分n * 3の命令かもしれない。共有メモリからキャッシュされた値をフェッチするときには、（20-40）* 5（最大バンク競合の最大値=推定値）=〜150クロックでコアは他の処理を行うことができます。カーネルがバインドされた（制限された）計算をしている場合は、共有メモリを使用するほうが効率的かもしれません。カーネルに共有メモリが限られている場合や、共有メモリを増やすと、飛行中のワープが少なくなった場合、再計算が高速になります。
fp乗算に1サイクルかかるのですか？ 5サイクル？ 私がthisと書いたのは6サイクルでしたが、それは7年前です。今や速くなるかもしれない（あるいはそうでないかもしれない）。これは、SM全体ではなく特定のコアに対してのみです。
どの時点で、いくつかの乗算として、共有メモリルックアップテーブルを使用することは意味がありますか？これは本当に難しいことです。 GPUの生成、カーネルの残りの部分、共有メモリのセットアップ時間など多くの変数があります。
カーネルに乱数を作成する際の問題は、追加のレジスタ要件です。これはカーネルの残りの部分の速度低下の原因になる可能性があります。これはレジスタの使用量が増え、占有量が少なくなるからです。
もう1つの解決策（問題に応じて）は、GPU RNGを使用して、グローバルメモリ配列に乱数を埋め込むことです。そして、あなたのカーネルにこれらをアクセスさせます。それは300〜500クロックサイクルかかるだろうが、銀行の競合はないだろう。また、Pascal（まだリリースされていない）ではhbm2があり、これによりグローバルメモリアクセス時間がさらに短縮される可能性があります。
これが役に立ちます。うまくいけば、他のいくつかの専門家がチャイムインしてより良い情報を伝えることができます。
さまざまな状況でこの状況を何度も見てきたので、私は実験的なアプローチを強く提案します。 GPU上でのプログラム実行の複雑さを考えると、公開されている情報に基づいて十分な精度で理論的にモデル化することはできません。 GPUでは、オンザフライ計算は頻繁にパフォーマンス面でルックアップテーブルよりも優れています。 – njuffa
実験的アプローチでnjuffraと同意する。これは、データのサイズに大きく依存します。データが読み取り専用の場合は非常に効率的なキャッシュもあります。これは定数キャッシュです。あなたのルックアップテーブルがそこに合っているなら、あなたは共有メモリと同じ規則を持たないので（割り当てを含む）、それを試してみたいです。 –