我有一个 NVIDIA GT650M,具有以下属性:
( 2) Multiprocessors, (192) CUDA Cores/MP: 384 CUDA Cores
Maximum number of threads per multiprocessor: 2048
Run Code Online (Sandbox Code Playgroud)
我刚刚摆脱了流式多处理器 (SM) 和实际多处理器之间的混淆。SM 和多处理器是不同的东西,对吧?例如,使用可视化分析器,我有一个虚拟内核,当以 1 个线程的 1 个块启动时,它只等待并持续 370 毫秒。我可以用一个 SM 用 4 个 1024 个线程块启动它,它仍然持续 370 毫秒。这是正常的,因为任务使用芯片的 2 个多处理器,每个使用 2048 个并发线程(我一使用 5 个块 x 1024,就需要 740 毫秒,正常)。同样,我可以使用 4 个 SM 并发启动 1024 个线程块的 4 次,它仍然需要 370 毫秒,好吧。
问题的第一部分只是为了确保我们不应该混淆 SM 和多处理器?就像我有时甚至在像这里这样的答案中看到的一样:CUDA - Multiprocessors, Warp size and Maximum Threads Per Block:确切的关系是什么? 因此,人们无法通过多处理器显式控制任务的调度方式,因为(据我所知)没有运行时函数允许它,对吗?那么,如果我的卡有 2 个多处理器,每个多处理器有 2048 个线程,或者另一个有 4 个多处理器,每个有 1024 个线程,给定的程序会以相同的方式执行吗?
其次,我想知道哪种用途更好,拥有更多内核较少的多处理器,还是相反?到目前为止,我的理解让我说,内核较少的更多多处理器(对于每个多处理器给定的最大线程)将更适合具有较少/简单操作的更大规模并行,而每个多处理器有更多内核(现在我正在谈论我几乎不知道的事情)将有更多专用 ALU 用于加载/存储操作和复杂的数学函数,因此它将更适合每个线程需要更多操作的内核?
这似乎是对术语的混淆。
“SM”(SM = Streaming Multiprocessor)和“多处理器”指的是同一个东西,一个硬件单元,它是 GPU 上的主要执行单元。这些术语指的是特定的硬件资源。不同的 GPU 可能有不同数量的 SM。可以使用 CUDAdeviceQuery 示例代码找到特定 GPU 的 SM 数量:
cudaDeviceProp deviceProp;
cudaGetDeviceProperties(&deviceProp, 0); // 0-th device
std::cout << deviceProp.multiProcessorCount;
Run Code Online (Sandbox Code Playgroud)
“启动”中的 CUDA 程序的元素是线程块。一个网格是所有的集合threadblocks与相关的内核启动。单个线程块在单个 SM 上执行。您可以在内核中启动大量线程块,或多或少独立于您正在运行的 GPU。然后,线程块将以特定 GPU 及其 SM 提供的任何速率进行处理。
没有 API 函数可以直接控制线程块到 SM 的调度。通过使用CUDA 流优先级,可以对来自并发运行的不同内核的线程块的调度进行某种程度的间接控制。
| 归档时间: |
|
| 查看次数: |
3162 次 |
| 最近记录: |