厳密なプログラミングの問題ではありませんが、ハードウェアを知ることはプログラミングの重要な部分です。
ここにいる人々が Kepler (GK10X または GK110) でのプログラミングの経験を共有できることを願っています。
まず私は私のものを始めます：
現在、GK110 でプログラミングを行っています。アプリケーションによっては、GK110 は Fermi よりも大幅に高速であり、理論上のピークに近くなっています (例: 2.5 ～ 3 倍高速)。しかし、そうでないものもあります (たとえば、50% から 60% しか速くなりません)。
私が間違っている場合は訂正してください。ただし、私には、Kepler の主なパフォーマンスのボトルネックは、ここではリソースのプレッシャーが非常に高いことです。
SM ごとのレベルでは、Fermi は実際には GK110 と比較してはるかに多くのリソースを持っています。各 SM で、Fermi は SIMT ユニットを 1 つしか持っていませんが、Kepler は 6 つ持っています。
それでも、各 SM では、Fermi には 32K のレジスタ ファイル、最大 1536 のアクティブなスレッドがありますが、Kepler の各 SM では、アクティブなスレッドは 33%、レジスタは 100%、命令発行ユニットは 800%、同じ量しかありません。 L1キャッシュの。
メモリと計算に関するレイテンシは、絶対的にはほぼ同じです (GPU サイクルに関しては半分)。
そのため、GF110 と比較して、GK110 ではリソースに対するプレッシャーがはるかに高くなります。
命令発行ユニットの 800% で、Nvidia はより積極的な TLP と ILP を使用して Kepler のレイテンシーを隠蔽したいと考えているようですが、L1 キャッシュは同じであり、アクティブなスレッドは 33 しか増加しないため、柔軟ではありません。 SIMT ユニットのように 500% ではなく % です。
したがって、Kepler の最大の効率を利用するには、はるかに困難です。最初のコードには、はるかに多くの ILP を含める必要がありますが、Kepler の大規模な命令発行ユニットを利用するには、共有メモリの使用量を大幅に減らす必要があります。次に、ワープごとにレベルでは、ワークフローは、ケプラー スケジュールがレイテンシを隠すために多くのワープを切り替える必要がないように、非常に計算集約的でなければなりません (そして、最初から選択できる利用可能なワープが多くないことは確かです)。