OpenCL：真正的挑战 - 页 6

[Roffild]

Mathemat: 我还没有在测试器中检查过它。

好吧，那你为什么要发表未经检查的胡言乱语？

也许我是唯一一个在测试器中尝试过OpenCL的人，毕竟......试过了...

[Sceptic Philozoff]

Roffild:

好吧，那你为什么要发表未经核实的胡言乱语？

我可能是唯一一个在测试器中使用过OpenCL的人，毕竟...。试过了...

这不是胡说八道，这是个满意的要求。

再次写信给Servicedesk，证明你想要的东西。如果你不能自圆其说，那是你的问题。

在写这些文章的时候，关于在测试器中使用OpenCL的讨论还没有真正开始。该申请指的正是那个时候。

你才应该开动你的大脑，因为0.35300毫秒指的是clEnqueue[Read/Write]Buffer()，而不是内核 内的全局内存访问。

这个命令在OpenCL for MQL5的实现中是不存在的。你在说什么呢？

[Vladimir Gomonov]

Roffild:

再看一下我的帖子。

主要标准： 以 "OpenCL风格 "执行MQL代码1次，必须超过时间 =Number_Buffers * 0.35300 ms

要知道MQL中算法的速度，精确到微秒（1000微秒=1毫秒），你必须在测试器和Total_Time / Number_of_Ticks（我的顶贴）中运行几次。

如果没有缓冲区延迟，我的代码将在30秒内通过测试 - 这比 "OpenCL风格 "的MQL（55秒）快2倍，比普通代码（320秒）快11倍。

还有什么其他标准？

我没有要求你重新阅读我在OpnCL的所有论坛帖子。:) A所有的基本标准都在那里描述和讨论。

主要标准是t_alg/t_mem比率，其中t_alg-计算内核 算法的优化时间，t_mem-删除（*）内存的访问时间。这个标准越长，通过OpenCL加速的前景就越好。 换句话说，计算量越大，进出设备的阵列传输越少，前景就越好。

(*) 远程内存=各种 "非寄存器 "内存（寄存器内存非常快），例如：(1)全局设备内存比寄存器内存慢得多，但比(2)设备外部的内存（CPU RAM）快得多。

[Roffild]

Mathemat:

这不是胡说八道，而是一个满意的应用。

再次写信给Servicedesk，证明你想要的东西。如果你不能自圆其说，那是你的问题。

再一次：从 2013.10.17 23:17 开始的 bug#865549 ，开发者被通知了，但不太可能修复什么。可能是他们中的某个人故意增加了这种限制，在优化期间不暂停整个处理器。

但文章中却只字未提!

数学。

是时候开动你的大脑了，因为0.35300毫秒指的是clEnqueue[Read/Write]Buffer()，而不是内核 内的全局内存访问。

这个命令在OpenCL for MQL5的实现中是不存在的。你在说什么呢？

呃...而你也在吐槽关于OpenCL的文章...

只是为了让你知道，clEnqueueReadBuffer= CLBufferRead和clEnqueueWriteBuffer= CLBufferWrite是同步调用。

学习从这里开始

MetaDriver：主要标准是比率t_alg/t_mem，其中t_alg是内核 算法的算法优化计算时间，t_mem是访问被删除（*）的内存的时间。换句话说，计算量越大，设备之间的阵列传输越少，OpenCL的加速潜力就越大。

这只是一个优化执行的标准。在我的帖子之前，没有关于缓冲区本身的传输率的近似数字。

[Roffild]

伙计们，在你们进一步争论之前，想想从这里开始的 三个帖子，特别是关于

mql5: 在这个特殊的例子中，使用OpenCL的优势被缓冲区复制的开销所吞噬了。

因为你专注于优化内核本身，而我的帖子是关于缓冲区的。

[Sceptic Philozoff]

Roffild: 只是为了让你知道：clEnqueueReadBuffer= CLBufferRead，clEnqueueWriteBuffer= CLBufferWrite，它们是同步调用的。

我早就知道MQL5的OpenCL实现只是真正的API的一个包装。顺便说一下，我在第二篇文章中写道，缺少设置工作小组大小的可能性。向servicedesk提出了请求，他们过了一会儿就办好了。

我也知道CLBuffer[Read/Write]与clEnqueue[Read/Write]Buffer相似，但这些函数完全不一样：它们的语法不同。

但我不明白你为什么一直在说 clEnqueueXXX 函数 ，而这些 函数 在MQL5的OpenCL中是不存在 的。

我会试着理解你的想法。

罗费尔德。

是时候开动你的大脑了，因为0.35300毫秒指的是clEnqueue[Read/Write]Buffer()，而不是内核 内的全局内存访问。

第二个问题可以通过优化内核本身来解决，而第一个问题是一个铁的限制。

好的。你对谁有怨言？显卡制造商？

[Roffild]

Mathemat: 我还知道CLBuffer[Read/Write]类似于clEnqueue[Read/Write]Buffer，但这些函数完全不一样：它们的语法不同。

但我不明白你为什么一直在说 clEnqueueXXX 函数 ，而这些 函数 在MQL5的OpenCL中是不存在 的。

那里没有任何区别。可能有这样的包装物。

template<typename T>
cl_int BufferWrite(cl_mem buffer, const T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueWriteBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}
template<typename T>
cl_int BufferRead(cl_mem buffer, T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueReadBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}

所以你也不必编造任何句法。第3个参数=CL_TRUE的事实已经被证实。

数学。

第二个问题可以通过优化内核本身来解决，而第一个问题是一个铁的约束，大脑不会帮助。

好的。你对谁有怨言？显卡制造商？

抱怨的是文章的作者，没有关于这个最重要的限制的实际数据!(没有，直到我测试了它）。

[Vladimir Gomonov]

Roffild:

抱怨是针对文章作者的，没有关于这个最重要的限制的实际数据!(没有，直到我测试了它）。

而且不要再读任何文章，你不会有任何抱怨。;)

--

你为什么要挑剔我？ 你怎么能在文章中引用未知的数据？ 数据传输到/从设备上的滞后是巨大的，必须考虑到这一点？ 具体数字取决于具体的硬件。 好吧，你已经在自己身上测试了，对你有好处。有时人们（包括我自己）会列出测试代码来估计不同硬件的能力和限制。他们要求其他人分享结果，人们经常这样做（为他们点赞），同时每个人都可以看到统计数据，以及在什么组合中起作用。然后有人重新购买硬件，或改变写代码的方法，以结果为导向。你想要什么？ 好吧，给Sportlotto写一份投诉，也许这将使你的代码工作得更快......

:)

[Roffild]

其实我已经在https://www.mql5.com/ru/forum/13715/page5#comment_646513， 但文章的作者自己想证明别的东西。

你的文章中没有具体的、非常重要的信息，所以它们没有完成，描述的是不现实的任务。

你可以不为文章添加信息，但假装这些特定的数字毫无意义是愚蠢的。

[Sceptic Philozoff]

我不明白你发布的脚本/顾问的隐藏含义，Roffild。说句不好听的，这段代码让人难以理解。

- cl_khr_fp64 pragma在哪里？在内核中用双数计算时，你需要它。

- 为什么在OnTick()函数 中会有这段代码，这段代码可以通过计算一次放在初始化中？

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);
local_work_size[0] = global_work_size[0] / units;

- 为什么全局任务的大小等于240字节？它必须大得多才能从OpenCL获得一些好处。好吧，如果你能仅仅通过眼睛来判断的话，它应该至少大一百万倍。

- 为什么全局任务要除以单位数才能得到局部任务的大小？CPU和GPU都允许将一个全局任务划分为数量更多的子任务。而单位在你的情况下，只是一些SIMD引擎。

例如，我的显卡有28个单元（Radeon HD7950）。但这个数字并不正好除以240。这意味着相当一部分的计算可能是不平行的。

我拥有的着色器数量是1792。你的是1440。这大概是你最好划分全局任务的数字，以正确加载地图。但你必须计算出正确的全局任务大小。(而且最好不要除以，而是乘以)。

而你的地图一直在计算什么，一点也不清楚。

简而言之：你的代码应该做什么？