OpenCL:真正的挑战 - 页 7

 

1) Pragmas是一个编译时支持的要求,而不是激活支持本身(正如你似乎认为的那样)。因此,如果你的操作系统支持cl_khr_fp64,它就已经参与了。

2) 如果数组大小在运行时发生变化呢?当然,在这个特定的代码中可以做到,但它不会使情况变得更好。

让我马上告诉你,我是在AMD CodeXL 中进行剖析。

3)如果我们 考虑内核本身的计算时间,任何在GPU上的并行任务都会通过利用CPU上更多的内核而获得好处。因此,即使是8个任务,也足以加快事情的进展。

4)我自己有很多关于本地计算公式的问题。最大的收益发生在work_dim=1时,我把任务分散到小工具的所有核心上,这就是UNITS。

为什么一般情况下要除以缓冲区的大小,而你应该除以其元素的数量?- 而我确实做到了。

Mathemat: 简而言之:你的代码要做什么?

表明准备计算的阶段不是瞬时的,缓冲区的转移需要大量的时间;这对使用OpenCL 的实用性提出了质疑,即使是在燃料任务中。

它还显示,在测试器中没有选择CPU。

 
Roffild:

表明计算的准备阶段并不是瞬间完成的,缓冲区的传输也需要大量的时间,这让人怀疑使用OpenCL 的实用性,即使是被夸大的任务。

也就是说,对它大喊大叫是相当愚蠢的;另一方面,测量它是另一回事;它可能有实际的作用。

它还显示,在测试器中没有选择CPU。

也许这是合理的,但也许是过度的保险。 无论如何,我相信这是有意识的,以确保测试过程本身的效率,或者说是优化(因为它是多线程的)。 在这里,如果测试和优化的概念被明确和完全分离(在党的政治层面),即它们被定义为测试人员使用的不同逻辑类型,那么实现包容的机会可能会出现。 有相应的(官方不同)软件支持。(这在很多方面都是好事,我是这种分离/区分的长期支持者。 就在不同的按钮上开始优化和测试)。

理论上,CPU的选择可以在测试期间被允许,而在优化期间不被允许(这是正确的)。

 
Roffild: 1) Pragmas是一个编译时的支持要求,而不是支持本身的激活(正如你所认为的那样)。也就是说,如果内脏支持的话,cl_khr_fp64就已经参与了。

是的,我在pragma上做得太过了。如果你将继续在你的小部件上工作,并且不把代码传给其他人,没有问题。但如果有人想在巴茨卡(比如说6870)上读取它,就会出现问题。内核代码将尝试执行而不显示错误。

4)我自己对本地的计算公式也有很多疑问。最大的收获是当work_dim=1将任务分散到小部件的所有核心上时,也就是UNITS。

不一定。增加内核本身的工作往往要有用得多。这是为了平衡与数据传输相关的开销。

而你的UNITS只是一些SIMD引擎。根据文件 规定。

local_work_size[] 设置一个任务子集,由指定的OpenCL程序内核来执行 它的维度等于 work_items[],并允许将总的任务子集切割成较小的子集,而没有分割残余 事实上, 必须选择 数组 local_work_size[]的大小 ,使全局任务集 work_items[] 被切成更小的子集 在这个例子中 local_work_size[3]={10, 10, 10} 就可以了 因为work_items[40, 100, 320] 可以从数组 local_items[10, 10, 10] 中组合出来,没有任何残留

SIMD引擎数是一个严格意义上的硬件常数,它根本不需要划分全局任务。

但首先你需要正确评估全球问题本身。

关于测试器中的CPU--我明白了,我被说服了。

 
MetaDriver:

嗯,这根本不是新闻。 我的意思是,为它尖叫是愚蠢的,但测量它完全是另一回事;它可以有实际的作用。

除了由于某些原因,我不得不进行这些测量...当你读到 "有一个传输延迟 "时,你不知道它有多大。

Mathemat: 而你的UNITS只是一些SIMD引擎。根据文件 规定。

SIMD引擎的数量是一个严格意义上的硬件常数,它根本不需要划分全局任务。

我们最好使用官方文件

CL_DEVICE_MAX_COMPUTE_UNITS cl_uint OpenCL设备上并行计算单元的数量。一个工作组在一个单一的计算单元上执行。 最小值为1。
本地_工作尺寸。
指向一个work_dim无符号值的数组,该数组描述了组成一个工作组 的工作项的数量(也称为工作组的大小),该工作组 将执行由内核指定的内核。
因此,我的结论是正确的,并被AMD CodeXL 运行所证实。
 

这一点是不同的。叫你的单位桶,但事实是,你的代码中的单位并没有把全局任务分成整数(我的当然没有:240/28不是整数;你的也是,因为你有单位=18)。这是一个错误。

其次,此时此刻,你正在使用 MQL5的OpenCL(嗯,这不对,但你懂的);这毕竟是一个不同于Khronos的OpenCL。

P.S. 我没有创建超链接,我只是自己得到了它 :)

Roffild:
CL_DEVICE_MAX_COMPUTE_UNITS cl_uint OpenCL设备上并行计算单元的数量。一个工作组在一个单一的计算单元上执行。 最小值为1。

关于 "计算单位 "的定义,见其他来源。

顺便说一下,这是我第二篇文章中的一个表格。如果你能理解所有这些计算单元(18)、流核心(288)、处理元素(1440)、最大波阵/GPU(496)和工作项目/GPU(31744),那就更好了。我还没有搞清楚。


 
Mathemat:

这一点是不同的。叫你的单位桶,但事实是,你的代码中的单位并没有把全局任务分成整数(我的当然没有:240/28不是整数;你的也是,因为你有单位=18)。这是个小故障。

那么你为什么要以240个字节为基础呢?你也许能做到,但显卡却做不到。因此,240/8=30个双打。

240字节是30个双数的整个缓冲区的大小。

而 "挑选一个完整的分割线 "只是官方文件的建议。而这个建议并不完美。

而关于UNITS的事,不是我自己的,只是来自OpenCL论坛的建议。我测试了一下,得到了最大的速度...

数学

第二件事:在这里,现在你正在使用 MQL5的OpenCL(嗯,这是不对的,但你得到了我),它毕竟是一个不同于Khronos的OpenCL。

那么 "另一个 "是什么呢?

你混淆了专有实现和简单的包装器。OpenCL MQL只是Khronos OpenCL API的一个封装器。关于OpenCL MQL和Khronos的区别。

 
Mathemat: 顺便说一下,这是我第二篇文章的表格。如果你能理解所有这些计算单元(18)、流核心(288)、处理元素(1440)、最大波阵/GPU(496)和工作项/GPU(31744),那就更好。我还没有搞清楚。

计算单元是同时执行的任务的数量。

max wavefronts/GPU(496)和work-items/GPU(31744)是排队运行的。

AMD CodeXL已经为所有这些问题提供了答案。

 
Roffild:

计算单元是同时执行的任务的数量。

max wavefronts/GPU(496)和work-items/GPU(31744)是执行队列。

AMD CodeXL最终可以帮助你 - 它回答了所有这些问题。

也许我有不明白的地方,对不起,但你认识阿列克谢本人吗?但从侧面看并不像.....,你说话太厚道了,比别人聪明?聪明不是罪,但在精神上的兄弟中夸耀它是可耻的......

 

我是一个简单的人,我回答的是重点。

如果你真的想了解OpenCL,而不仅仅是假设,你将不得不把AMD CodeXL和创建自己的C/C++包装器。

我可以把我的包装器贴出来,但由于我缺乏C/C++的实践,它有一些不合逻辑的行。

 
Roffild: 那么你为什么要以240字节为基数呢?你也许能做到,但显卡不能。因此,240/8=30个双打。

240字节是整个30个双数的缓冲区的大小。

看看你自己的代码。

uint units = (uint)CLGetInfoInteger(hcontext, CL_DEVICE_MAX_COMPUTE_UNITS);
uint global_work_offset[] = {0};
uint global_work_size[1];
uint local_work_size[1];
global_work_size[0] = ArraySize(price);
Print( "Глобальная задача = ", global_work_size[0] );  /// Это я добавил, вышло 240. Но это и так легко подсчитать: 30*double = 240
local_work_size[0] = global_work_size[0] / units;

此外,在最后一行,你自己用240除以18(这些是你地图的单位)。

而 "捡起整个隔板 "只是官方文件中的一个建议。而这个建议并不完美。

我们正在使用MQL5 OpenCL。我指的是我们网站上的文件。当然,我也在看Khronos。

至于UNITS,这不是我自己说的,而是OpenCL论坛的一些建议。我已经测试过了,得到了最大的速度...

好吧,我在不同的参数下得到了最大的速度。那么?

让我们给你一个大致的概念。在GPU上同时运行的18个任务,是4-5串CPU所能完成的最大值。而x86模拟的CPU可以组织更多的线程。至少如果是英特尔的话。我以前的奔腾G840(2个核心)给出了大约70倍的加速度--在两台设备上!这是我的经验。更不用说我现在的...可以说是i7。

一个良好的并行化的任务(看看第一个ocl分支的MetaDriver 脚本)可以在GPU上达到1000以上的速度(与MQL5的CPU上的一个线程相比)。如果你找不到它--我可以为你下载它,在你的卡片上试试。

如果你真的想了解OpenCL,而不仅仅是猜测,你将不得不把AMD CodeXL和创建自己的C/C++包装器。

好的,我会看一下的,谢谢。