当我在 Windows 7（相对于 Linux）中运行 CUDA 应用程序时，我注意到性能受到很大影响。我想我可能知道减速发生在哪里：无论出于何种原因，Windows Nvidia 驱动程序（版本 331.65）在通过运行时 API 调用时都不会立即调度 CUDA 内核。为了说明问题，我分析了 mergeSort 应用程序（来自 CUDA 5.5 附带的示例）。
首先考虑在 Linux 中运行时的内核启动时间：
接下来，考虑在 Windows 中运行时的启动时间：
这篇文章表明该问题可能与批处理内核启动的 Windows 驱动程序有关。无论如何我可以禁用此批处理吗？
我正在使用 GTX 690 GPU、Windows 7 和 Nvidia 驱动程序的 331.65 版本运行。
通过 WDDM 堆栈发送 GPU 硬件命令有相当多的开销。
正如您所发现的，这意味着在 WDDM（仅）下，GPU 命令可以“分批”以分摊此开销。批处理过程可能（可能会）引入一些延迟，这可能是可变的，具体取决于其他情况。
windows下最好的解决方案是将GPU的运行模式从WDDM切换到TCC，这可以通过nvidia-smi命令来完成，但它只支持Tesla GPU和Quadro系列GPU的某些成员——即不支持GeForce。（它还具有阻止设备用作 Windows 加速显示适配器的副作用，这可能与 Quadro 设备或一些特定的旧 Fermi Tesla GPU 有关。）
AFAIK 没有正式记录的方法来规避或影响驱动程序中的 WDDM 批处理过程，但我非正式地听说，根据此链接中的 Greg@NV，在 cuda 内核调用之后发出的命令cudaEventQuery(0);可能/应该导致WDDM 批处理队列“刷新”到 GPU。
正如 Greg 指出的那样，广泛使用这种机制将消除摊销收益，并且弊大于利。
编辑：前进到 2016 年，对 WDDM 命令队列的“低影响”刷新的更新建议将是cudaStreamQuery(stream);
EDIT2：在 Windows 上使用最新的驱动程序，您应该能够将 Titan 系列 GPU 置于 TCC 模式，假设您为主显示器设置了一些其他 GPU。该nvidia-smi工具将允许您切换模式（nvidia-smi --help用于获取更多信息）。
有关 TCC 驱动程序模型的其他信息可以在windows 安装指南中找到，包括它可以减少内核启动的延迟。
关于 TCC 支持的声明是一般性的。并非所有 Quadro GPU 都受支持。在特定 GPU 上支持（或不支持）TCC 的最终决定因素是nvidia-smi工具。此处的任何内容都不应被解释为在您的特定 GPU 上支持 TCC 的保证。
即使这个问题已经活跃了将近 3 年，我仍然认为有必要提供我的发现。
我遇到过同样的情况：相同的 cuda 程序在 Ubuntu cuda 8.0 中运行了 5 毫秒，而在 Windows 10 cuda 10.1 中运行了超过 30 毫秒。两者都配备 GTX 1080Ti。但是，在 Windows 中，当我将编译器从 VS Studio 更改为 cmd 的 nvcc 编译器时，程序突然被提升到与 Linux 相同的速度。
这表明问题可能来自 Visual Studio。