我試圖通過使用並行Nsight 2.1版爲2010年VS內核啓動和內核執行之間的時間
我的程序優化我的CUDA PROGRAMM在Windows 7（32位）的機器上運行了GTX 480板。我已經安裝了CUDA 4.1 32位工具包和301.32驅動程序。
程序中的一個循環包含主機數據副本到設備，執行內核和從設備到主機的結果副本。
正如您在下面的分析器結果圖片中看到的，內核運行在四個不同的流中。每個流中的內核依賴於複製到「流2」中的設備的數據。這就是爲什麼在啓動不同流中的內核之前，asyncMemcpy與CPU同步的原因。
什麼讓我惱火的圖片是第一個內核啓動（在10.5778679285）的結束和內核開始執行時（在10.5781500）之間的差距較大。大約需要300美元才能啓動內核，這在處理週期小於1毫秒時是一個巨大的開銷。
此外，內核執行和結果的數據副本不會重疊回主機，這會增加開銷。
這種行爲是否有任何明顯的原因？
我可以通過跟蹤分辨出三個問題。
Nsight CUDA分析爲每個API調用增加了大約1μs。您同時啓用了CUDA運行時和CUDA Driver API跟蹤。如果您要禁用CUDA運行時跟蹤，我猜測您會將寬度減少50μs。
由於您使用的是Windows 7上的GTX 480，因此您正在執行WDDM驅動程序模型。在WDDM上，驅動程序必須進行內核調用才能提交工作，這會帶來很多開銷。爲避免減少這種開銷，CUDA驅動程序緩存內部SW隊列中的請求，並在隊列滿時通過同步調用刷新請求，將請求發送給驅動程序。有可能使用cudaEventQuery來強制驅動程序刷新工作，但這可能會產生其他性能影響。
看來你是以深度優先的方式將工作提交給流。在計算能力2.x和3.0設備上，如果您以寬度優先的方式提交流，您將會獲得更好的結果。在你的情況下，你可能會看到你的內核之間的重疊。
的時間表截圖沒有提供足夠的信息讓我確定爲什麼內存副本所有內核完成後開始。鑑於API調用模式I，您應該能夠看到在每個流完成啓動後開始傳輸。
如果您正在等待所有流完成，那麼執行cudaDeviceSynchronize的速度可能比4個cudaStreamSynchronize調用的速度快。
Nsight的下一個版本將具有其他功能，以幫助瞭解SW排隊和將工作提交到計算引擎和內存複製引擎。