这个问题与使用 cuda 流运行许多内核有关
CUDA中有很多同步命令
cudaStream同步，
CudaDeviceSynchronize,
cudaThread同步，
还有 cudaStreamQuery 检查流是否为空。
我注意到在使用分析器时，这些同步命令会给程序带来很大的延迟。我想知道是否有人知道除了使用尽可能少的同步命令之外的任何方法来减少这种延迟。
也有没有什么数字来判断最有效的同步方法。那就是考虑在一个应用程序中使用了 3 个流，其中两个需要完成才能让我启动第四个流我应该使用 2 个 cudaStreamSyncs 还是只使用一个 cudaDeviceSync 什么会减少损失？
最佳答案
同步方法之间的主要区别是“轮询”和“阻塞”。
“轮询”是驱动程序等待 GPU 的默认机制——它等待 32 位内存位置达到 GPU 写入的某个值。它可能会在等待解决后更快地返回等待，但在等待时，它会烧毁查看该内存位置的 CPU 内核。
可调用 cudaSetDeviceFlags() 请求“阻止”与 cudaDeviceScheduleBlockingSync , 或调用 cudaEventCreate()与 cudaEventBlockingSync .阻塞等待导致驱动程序将命令插入 DMA 命令缓冲区，当缓冲区中的所有先前命令都已执行时，该命令会发出中断信号。然后，驱动程序可以将中断映射到 Windows 事件或 Linux 文件句柄，使同步命令能够等待而不会像默认轮询方法那样不断地烧毁 CPU。
查询基本上是手动检查用于轮询等待的 32 位内存位置；所以在大多数情况下，它们非常便宜。但是如果启用了 ECC，查询将进入内核模式检查是否有任何 ECC 错误；在 Windows 上，任何挂起的命令都将刷新到驱动程序(这需要内核 thunk)。
关于concurrency - 如何减少 CUDA 同步延迟/延迟，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11953722/