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;
1) Pragmas是一个编译时支持的要求，而不是激活支持本身（正如你似乎认为的那样）。因此，如果你的操作系统支持cl_khr_fp64，它就已经参与了。
2) 如果数组大小在运行时发生变化呢？当然，在这个特定的代码中可以做到，但它不会使情况变得更好。
让我马上告诉你，我是在AMD CodeXL 中进行剖析。
3）如果我们只 考虑内核本身的计算时间，任何在GPU上的并行任务都会通过利用CPU上更多的内核而获得好处。因此，即使是8个任务，也足以加快事情的进展。
4）我自己有很多关于本地计算公式的问题。最大的收益发生在work_dim=1时，我把任务分散到小工具的所有核心上，这就是UNITS。
为什么一般情况下要除以缓冲区的大小，而你应该除以其元素的数量？- 而我确实做到了。
表明准备计算的阶段不是瞬时的，缓冲区的转移需要大量的时间；这对使用OpenCL 的实用性提出了质疑，即使是在燃料任务中。
它还显示，在测试器中没有选择CPU。
表明计算的准备阶段并不是瞬间完成的，缓冲区的传输也需要大量的时间，这让人怀疑使用OpenCL 的实用性，即使是被夸大的任务。
也就是说，对它大喊大叫是相当愚蠢的；另一方面，测量它是另一回事；它可能有实际的作用。
它还显示，在测试器中没有选择CPU。
也许这是合理的，但也许是过度的保险。 无论如何，我相信这是有意识的，以确保测试过程本身的效率，或者说是优化（因为它是多线程的）。 在这里，如果测试和优化的概念被明确和完全分离（在党的政治层面），即它们被定义为测试人员使用的不同逻辑类型，那么实现包容的机会可能会出现。 有相应的（官方不同）软件支持。(这在很多方面都是好事，我是这种分离/区分的长期支持者。 就在不同的按钮上开始优化和测试)。
理论上，CPU的选择可以在测试期间被允许，而在优化期间不被允许（这是正确的）。
是的，我在pragma上做得太过了。如果你将继续在你的小部件上工作，并且不把代码传给其他人，没有问题。但如果有人想在巴茨卡（比如说6870）上读取它，就会出现问题。内核代码将尝试执行而不显示错误。
不一定。增加内核本身的工作往往要有用得多。这是为了平衡与数据传输相关的开销。
而你的UNITS只是一些SIMD引擎。根据文件 规定。
SIMD引擎数是一个严格意义上的硬件常数，它根本不需要划分全局任务。
但首先你需要正确评估全球问题本身。
关于测试器中的CPU--我明白了，我被说服了。
嗯，这根本不是新闻。 我的意思是，为它尖叫是愚蠢的，但测量它完全是另一回事；它可以有实际的作用。
除了由于某些原因，我不得不进行这些测量...当你读到 "有一个传输延迟 "时，你不知道它有多大。
Mathemat: 而你的UNITS只是一些SIMD引擎。根据文件 规定。
SIMD引擎的数量是一个严格意义上的硬件常数，它根本不需要划分全局任务。
我们最好使用官方文件。
指向一个work_dim无符号值的数组，该数组描述了组成一个工作组 的工作项的数量（也称为工作组的大小），该工作组 将执行由内核指定的内核。
这一点是不同的。叫你的单位桶，但事实是，你的代码中的单位并没有把全局任务分成整数（我的当然没有：240/28不是整数；你的也是，因为你有单位=18）。这是一个错误。
其次，此时此刻，你正在使用 MQL5的OpenCL（嗯，这不对，但你懂的）；这毕竟是一个不同于Khronos的OpenCL。
P.S. 我没有创建超链接，我只是自己得到了它 :)
关于 "计算单位 "的定义，见其他来源。
顺便说一下，这是我第二篇文章中的一个表格。如果你能理解所有这些计算单元（18）、流核心（288）、处理元素（1440）、最大波阵/GPU（496）和工作项目/GPU（31744），那就更好了。我还没有搞清楚。
这一点是不同的。叫你的单位桶，但事实是，你的代码中的单位并没有把全局任务分成整数（我的当然没有：240/28不是整数；你的也是，因为你有单位=18）。这是个小故障。
那么你为什么要以240个字节为基础呢？你也许能做到，但显卡却做不到。因此，240/8=30个双打。
240字节是30个双数的整个缓冲区的大小。
而 "挑选一个完整的分割线 "只是官方文件的建议。而这个建议并不完美。
而关于UNITS的事，不是我自己的，只是来自OpenCL论坛的建议。我测试了一下，得到了最大的速度...
第二件事：在这里，现在你正在使用 MQL5的OpenCL（嗯，这是不对的，但你得到了我），它毕竟是一个不同于Khronos的OpenCL。
那么 "另一个 "是什么呢？
你混淆了专有实现和简单的包装器。OpenCL MQL只是Khronos OpenCL API的一个封装器。关于OpenCL MQL和Khronos的区别。
计算单元是同时执行的任务的数量。
max wavefronts/GPU（496）和work-items/GPU（31744）是排队运行的。
AMD CodeXL已经为所有这些问题提供了答案。
计算单元是同时执行的任务的数量。
max wavefronts/GPU（496）和work-items/GPU（31744）是执行队列。
AMD CodeXL最终可以帮助你 - 它回答了所有这些问题。
也许我有不明白的地方，对不起，但你认识阿列克谢本人吗？但从侧面看并不像.....，你说话太厚道了，比别人聪明？聪明不是罪，但在精神上的兄弟中夸耀它是可耻的......
我是一个简单的人，我回答的是重点。
如果你真的想了解OpenCL，而不仅仅是假设，你将不得不把AMD CodeXL和创建自己的C/C++包装器。
我可以把我的包装器贴出来，但由于我缺乏C/C++的实践，它有一些不合逻辑的行。
240字节是整个30个双数的缓冲区的大小。
看看你自己的代码。
此外，在最后一行，你自己用240除以18（这些是你地图的单位）。
而 "捡起整个隔板 "只是官方文件中的一个建议。而这个建议并不完美。
我们正在使用MQL5 OpenCL。我指的是我们网站上的文件。当然，我也在看Khronos。
好吧，我在不同的参数下得到了最大的速度。那么？
让我们给你一个大致的概念。在GPU上同时运行的18个任务，是4-5串CPU所能完成的最大值。而x86模拟的CPU可以组织更多的线程。至少如果是英特尔的话。我以前的奔腾G840（2个核心）给出了大约70倍的加速度--在两台设备上！这是我的经验。更不用说我现在的...可以说是i7。
一个良好的并行化的任务（看看第一个ocl分支的MetaDriver 脚本）可以在GPU上达到1000以上的速度（与MQL5的CPU上的一个线程相比）。如果你找不到它--我可以为你下载它，在你的卡片上试试。
好的，我会看一下的，谢谢。