我想我对 CUDA 编程模型和一般编程很陌生。我正在尝试并行化期望最大化算法。我正在研究具有计算能力 2.0 的 gtx 480。起初，我有点认为设备没有理由启动自己的线程，但当然，我错了。我遇到了这个pdf。
http://docs.nvidia.com/cuda/pdf/CUDA_Dynamic_Parallelism_Programming_Guide.pdf
不幸的是，动态并行只适用于最新最好的 GPU，计算能力为 3.5。如果不深入探讨太多细节，动态并行的替代方案是什么？CPU EM 算法中的循环有很多依赖关系并且是高度嵌套的，这似乎使动态并行性成为一种有吸引力的能力。我不确定我的问题是否有意义，所以请询问您是否需要澄清。
谢谢！
正如@JackOLantern 所指出的，动态并行性可以简单地描述为__global__从设备代码（a__global__或__device__函数）调用内核（即函数）的能力。
由于内核调用是机器启动多个线程以响应单个函数调用的主要方法，因此实际上没有直接的替代方法可以在不支持它的设备中提供所有动态并行能力（即 pre cc 3.5 设备）。
如果没有动态并行，您的整体代码几乎肯定会涉及 CPU 代码和 GPU 代码之间的更多同步和通信。
主要方法是将代码的某些单元实现为可并行化，将其转换为内核，并以本质上非嵌套的方式处理您的代码。重复功能可以通过在内核中循环来完成，或者在调用内核的主机代码中循环。
有关我试图描述的图形示例，请参阅本套牌的幻灯片 14，其中介绍了 CUDA 5 的一些新功能，包括动态并行性。右边的代码架构是动态并行实现的算法。左边的架构是在没有动态并行的情况下实现的相同功能。
我已经在 Wikipedia 中检查了您的算法，但我不确定您是否需要动态并行。
您在内核中执行期望步骤__syncthreads()，执行最大化步骤，然后__syncthreads()再次执行。从这个距离来看，期望看起来像一个归约原语，而最大化是一个过滤器。
如果它不起作用，并且您需要真正的任务并行性，那么 GPU 可能不是最佳选择。虽然 Kepler GPU 在某种程度上可以做到这一点，但这并不是该架构的设计目的。在这种情况下，您最好使用多 CPU 系统，例如办公室网格、超级计算机或 Xeon Phi 加速器。您还应该检查 OpenMP 和 MPI，它们是用于任务并行编程的语言（实际上，在大多数情况下，OpenMP 只是少数 pragma）。