这个问题与使用cuda流运行多个内核有关
CUDA中有很多同步命令
cudaStream同步，
Cuda设备同步，
cuda线程同步，
还有 cudaStreamQuery 来检查流是否为空。
我注意到在使用探查器时，这些同步命令会给程序带来很大的延迟。我想知道是否有人知道减少这种延迟的任何方法，当然除了使用尽可能少的同步命令之外。
还有有没有数字来判断最有效的同步方法。考虑在一个应用程序中使用 3 个流，其中两个需要完成才能启动第四个流，我应该使用 2 个 cudaStreamSync 还是仅使用一个 cudaDeviceSync，什么会产生更少的损失？
同步方法之间的主要区别是“轮询”和“阻塞”。
“轮询”是驱动程序等待 GPU 的默认机制 - 它等待 32 位内存位置以获得 GPU 写入的某个值。在等待解决后，它可能会更快地返回等待，但在等待时，它会消耗查看该内存位置的 CPU 核心。
可以通过致电请求“阻止”cudaSetDeviceFlags() with cudaDeviceScheduleBlockingSync，或致电cudaEventCreate() with cudaEventBlockingSync。阻塞等待会导致驱动程序将命令插入 DMA 命令缓冲区，当缓冲区中所有前面的命令都已执行时，该命令会发出中断信号。然后，驱动程序可以将中断映射到 Windows 事件或 Linux 文件句柄，从而使同步命令能够等待，而不会像默认轮询方法那样不断消耗 CPU。
查询基本上是对用于轮询等待的 32 位内存位置的手动检查；所以在大多数情况下，它们非常便宜。但如果启用了 ECC，查询将进入内核模式以检查是否存在任何 ECC 错误；在 Windows 上，任何待处理的命令都将刷新到驱动程序（这需要内核 thunk）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
