【问题标题】:What is the algorithm to determine optimal work group size and number of workgroup确定最佳工作组大小和工作组数量的算法是什么
【发布时间】:2012-04-10 21:04:06
【问题描述】:

OpenCL 标准定义了以下选项来获取有关设备和编译内核的信息:

  • CL_DEVICE_MAX_COMPUTE_UNITS

  • CL_DEVICE_MAX_WORK_GROUP_SIZE

  • CL_KERNEL_WORK_GROUP_SIZE

  • CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE

给定这些值,我如何计算工作组的最佳大小和工作组的数量?

【问题讨论】:

    标签: opencl


    【解决方案1】:

    您通过实验为您的算法发现这些值。使用分析器获取硬数字。

    我喜欢使用 CL_DEVICE_MAX_COMPUTE_UNITS 作为工作组的数量,因为我经常依赖于同步工作项。我通常运行很少分支的内核,因此在每个计算单元中执行的时间相同。

    CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE 的某些倍数最适合您的设备。这个倍数实际上取决于您的内存访问模式和您对每个工作项所做的工作类型。当您运行繁重的计算密集型 (ALU) 内核时,请使用 1 作为倍数。如果您受到内存访问的瓶颈,请尝试使用更大的倍数来隐藏内存延迟。使用分析器来确定您的访问时间和 ALU 时间何时最佳。

    对于任何设备,ALU 获取的最佳比率是 1:1。这在实践中很少实现,因此您希望保持 ALU/SIMD 组饱和。这意味着 ALU:fetch 应尽可能大于 1。小于 1 意味着您应该尝试更大的工作组大小以更好地隐藏内存延迟。

    【讨论】:

    • 我的目标是支持一系列设备。这是否意味着,我必须在每个内核上测试我的内核以获得内核排队的最佳值?
    • 在您可以访问的设备上测试您的算法——结果不应有太大差异。我建议在您想要定位的每个主要架构的一个设备上尝试它。如果可以,请在运行时调整参数以尝试优化。这可以调整您在开发过程中发现的最佳值。从最终用户/客户那里获得有关实际硬件数量的反馈将使您能够将改进重点放在最常见的设备上。
    • 通常使用CL_DEVICE_MAX_COMPUTE_UNITS 不会给您最佳性能(除非您在工作组之间进行大量同步,但这通常是个坏主意)。我通常会要求文档提供良好的价值,但我从未见过更多的工作组损害性能,所以越多越好。请注意,只有在您没有使用足够的工作组(例如 CL_DEVICE_MAX_COMPUTE_UNITS,因为 CU 通常一次可以维持一个以上的工作组)时,关于选择更高的工作组大小来隐藏内存延迟的部分(至少对于 gpus)才是正确的。
    • @Grizzly 我知道 CL_DEVICE_MAX_COMPUTE_UNITS 作为工作组的数量是个坏主意。我用它作为乘数。例如。 10 * CL_DEVICE_MAX_COMPUTE_UNITS。我仍然对基于运行时的方法来确定首选工作组的大小和数量感兴趣,因为我通常必须将几十个子任务排入一个主要任务中。
    【解决方案2】:

    正如 mfa 所说,您必须通过实验来发现这些。 我想补充一点,这取决于您正在计算的内容(特别是作业的大小,即每个工作项的大小),有时一个好的尝试可以是:

    • 很多工作项,工作组很小,每个工作项都很小。
    • 工作组越大,工作项越少,每个工作项越大。

    也就是说,基本上检查基本情况并弄清楚它如何影响处理管道。

    本质上你必须调整它。我经常针对不同的参数执行几次(分析它),然后生成一个曲面图来查看它的行为。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2015-07-21
      • 1970-01-01
      • 1970-01-01
      • 2015-12-26
      • 2018-06-06
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多