OpenCl和它的工具。评论和印象。 - 页 6 12345678910111213...29 新评论 Sceptic Philozoff 2012.01.30 22:05 #51 我怀疑这就是一个月前米切克 所喊的事情。 我认为OpenCL的应用是在重度测试或非常密集的即时并行计算中。 到目前为止，我还不需要它（所有繁重的计算都在我的电感的init()中），但它值得一提。 Алексей Тарабанов 2012.01.30 22:14 #52 Alexey，我也有同样的问题：我试图把一些东西拖到init，然后再拖到实时:) 我的大脑被打开了，是一种程序性语言。OOP是可取的，但不是原生的。 [删除] 2012.01.31 04:22 #53 MetaDriver: 对于那些不访问mql5.com的狂热的B4粉丝：OpenCL：在MQL5中实现的内部测试 谢谢，我个人没有看到这一条。只不过，这并不那么简单。 此外，Rinat在混淆视听：OpenCL 1.0可以很好地使用双浮点，这是所有制造商都支持的 "公共选项"--但不是针对所有旧地图。 http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/ "可选双精度和半浮点 OpenCL 1.0增加了对双精度和半浮点的支持，作为可选的扩展。双重 数据类型必须确认为IEEE-754双精度存储格式。 想要使用双 精度的应用程序需要在内核代码中声明任何双精度数据类型之前加入#pragma OPENCL EXTENSION cl_khr_fp64 : enable 指令。这将扩展内置矢量和标量数据类型的列表，包括以下内容：....."。 它可以在策略测试器中工作，但在OpenCL 1.0专家顾问中不能工作，不是因为如Rinat所说的 "那里没有双浮点"，而是如我已经提到的，因为OpenCL 1.0中没有安全线程，MT4-5中也没有线程。 OpenCL（和CUDA）在总体上是混乱的。你想要什么？毕竟，铁和无线电工程师们着手改变编程的概念。他们有一种铁的心态。 所谓的 "平台选择 " 也会有问题： 程序，即MT或DLL或Expert Advisor，必须，就是必须选择平台（AMD、Nvidia、Intel），这可能是几个不同的平台，将运行OpenCL连接器，然后手动选择DEVICE，如果你的电脑是运行多GPU。OpenCL中的平台自动选择功能还没有出现。Rinat谈到了 "自动选择最强大的"，但我不知道它是怎样的。在那里显示的例子中，没有平台选择，也没有设备选择（GPU、CPU）。 此外，在标准中还没有对多个GPU或GPU+CPU上的任务进行自动OpenCL并行化。让我们这样说吧：在某些版本的驱动/SDK中，AMD曾经引入了这种自动配置，但出现了一些问题，目前AMD已经关闭了这个功能。 一句话：开发和启用OpenCL程序需要一些手工操作，因此不会自动工作或通过 "用选项重新编译"。这在实际操作中又充满了大量的停顿。这将是一项微妙的工作，重要的是，我允许自己重复，不幸的是，这是以犹太人为导向的程序，这是错误的。调试CUDA或OpenCL的并行程序比钢铁革命者假设的要困难得多。Nvidia甚至取消了他们的2011年秋季CUDA会议--由于驱动问题和大量关于停滞调试的投诉。因此，他们在最新的工具包中又 增加了1000个新功能--如果最简单的程序甚至不能运行或运行时出现中断，那该怎么办？毕竟，他们在描述性工具中甚至没有提到OpenCL或CUDA的一半内部机制。 由于驱动或软件的兼容性，悬挂的显卡的GPU速度（单位：GigaFLOPS）为零。 OpenCL：MQL5中的内部实现测试 Andrey Dik 2012.01.31 05:24 #54 AlexEro: 谢谢你，我本人还没有看到。只不过，这并不那么简单。 .... 请在第五论坛上回信。 Sceptic Philozoff 2012.01.31 13:30 #55 tara: 脑子已经转到了程序性语言上。OOP是可取的，但不是原生的。 这并不是真正的重点。你可以用程序化的方式在五号文件上写作。 joo: 而且 ，我对这一事实感到灰心，阿克纠!-MQL4调用dll的速度比MQL5调用相同dll的速度快... 这就是令人震惊之处。 他们本可以在MQL5中开发对OMP的本地支持。这对编码者来说很容易，也很便宜，而且不需要编写任何dll。 但这群蜜蜂在不完整的铁质编程语言中...还不能完全激发我的兴趣。嗯，是的，在某些情况下百倍加速是很好的，但就编程文化而言，它是一种退步。 Igor Chemodanov 2012.01.31 13:46 #56 ... 在OpenCL（和CUDA）中，一般来说有很多困惑。你想要什么？毕竟，铁和无线电工程师已经着手改变编程的概念。他们有一种铁的心态。 所谓的 "平台选择 " 也会有问题： 程序，即MT或DLL或Expert Advisor，必须，就是必须选择平台（AMD、Nvidia、Intel），这可能是几个不同的平台，将运行OpenCL连接器，然后手动选择DEVICE，如果你的电脑是运行多GPU。OpenCL中的平台自动选择功能还没有出现。Rinat谈到了 "自动选择最强大的"，但我不知道它是怎样的。在那里显示的例子中，没有平台选择，也没有设备选择（GPU、CPU）。 此外，目前还没有标准的方法来自动将OpenCL任务在几个GPU或GPU+CPU之间并行化。让我们这样说吧：在其驱动/SDK的某些版本中，AMD曾经实现了这种自动并行化，但出现了一些问题，迄今为止AMD已经将其关闭。 一句话：开发和启用OpenCL程序需要一些手工操作，因此不会自动工作或通过 "用选项重新编译"。这在实际操作中又充满了大量的停顿。这将是一项微妙的工作，重要的是，我允许自己重复，不幸的是，这是以犹太人为导向的程序，这是错误的。调试CUDA或OpenCL的并行程序比钢铁革命者假设的要困难得多。Nvidia甚至取消了他们的2011年秋季CUDA会议--由于驱动问题和大量关于停滞调试的投诉。因此，他们在最新的工具包中又 增加了1000个新功能--如果最简单的程序甚至不能运行或运行时出现中断，那该怎么办？毕竟，他们在描述性工具中甚至没有提到OpenCL或CUDA的一半内部机制。 由于驱动或软件的兼容性，悬挂的显卡的GPU速度（单位：GigaFLOPS）等于零。 "这就对了，这就对了，不是吗？但硬币还有另一面。"（《高加索俘虏》，C）。元引号终于 "与时俱进 "了。而你的问题（正确）不是他们的问题，而是硬件、木材和操作系统开发者的问题。 Mykola Demko 2012.01.31 14:56 #57 Mathemat: 这并不是真正的重点。你也可以在5号文件中以程序化的方式写作。 但这是令人震惊的。 他们本可以在MQL5中开发对OMP的本地支持。这很简单，也很干净，不需要写dll。 但这群蜜蜂在一个不完整的硬件编程语言中.........似乎不是很刺激。是的，在某些情况下，百倍的速度是伟大的，但就编程文化而言，它是一种退步。 我也遇到过mql4比MQL5更快工作的事实。在大多数情况下，它表现为由程序员优化的数学运算。 但我认为这不是主要问题--通过使用OpenCL MQ，他们走上了一条与主要编程路径平行的道路--也许到目前为止，这需要退一步，但在未来的计算机技术发展中，我们将看到集成的可扩展系统，在那里，是使用顺序处理还是并行处理，已经取决于代码了。 所以道路是很正确的。虽然现在没有那么多要求 实施并行方法的算法，但这是因为数学思想没有实施并行计算的设备，因此没有必要创造这种算法。 阿列克谢，想想一个事实，所有的数学发现都是在200-300年前做出的，最近100年的数学思想只是在打磨现有的东西。只有NS的发现才产生了对平行计算的需求。未来100年，将看到大量的平行算法。而你，包括其他人，可以发明其中的一个。 Vladimir Gomonov 2012.01.31 15:09 #58 Urain: 我也看到过mql4比MQL5快的事实。这最常出现在由程序员优化的矩阵运算中。 但我认为这不是主要问题--通过进入OpenCL，MQ已经走上了一条与主要编程道路平行的道路；也许到目前为止，这需要退一步，但在计算机技术的未来发展中，我们将看到集成的可扩展系统，在那里，是使用顺序处理还是并行处理，已经取决于代码了。 所以道路是很正确的。虽然现在没有那么多要求 实施并行方法的算法，但这是因为数学思想没有实施并行计算的设备，因此没有必要创造这种算法。 阿列克谢，只考虑一个事实，所有的数学发现都是在200-300年前完成的，过去100年的数学思想只是在打磨现有的东西。只有NS的发现才形成了对平行计算的需求。未来100年，将看到大量的平行算法。而你，包括其他人，可以发明其中的一个。 不，你毕竟不是完全没有希望。:) 你好。 Andrey Dik 2012.01.31 15:23 #59 MQ是好的，他们不怕处理这样的痛苦（对他们来说），如引入对GPU计算的支持。痛苦，首先是与以下事实有关：引进根本性的新技术（任何），一开始就降低了整个平台的可靠性和容错性。但他们完全明白，未来属于并行计算，他们迟早会在这个方向上有所作为（第一步已经迈出--云）。 PS 嗨，尼古拉。你为什么会消失？- 请给我留言。 Sceptic Philozoff 2012.01.31 16:02 #60 Urain: 阿列克谢，只考虑一个事实，所有的数学发现都是在200-300年前完成的，过去100年的数学思想只是在打磨现有的东西。而只有NS的发现形成了对平行计算的需求。 这不是一个事实，因为它不是。数学的质的发展从未中断过。 而并行计算不仅是NS所需要的，还有更多平凡的任务--比如视频编码或渲染。 但是，MQ运动的总体方向无疑是令人鼓舞的。 12345678910111213...29 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我怀疑这就是一个月前米切克 所喊的事情。
我认为OpenCL的应用是在重度测试或非常密集的即时并行计算中。
到目前为止，我还不需要它（所有繁重的计算都在我的电感的init()中），但它值得一提。
Alexey，我也有同样的问题：我试图把一些东西拖到init，然后再拖到实时:)
我的大脑被打开了，是一种程序性语言。OOP是可取的，但不是原生的。
对于那些不访问mql5.com的狂热的B4粉丝：OpenCL：在MQL5中实现的内部测试
谢谢，我个人没有看到这一条。只不过，这并不那么简单。
此外，Rinat在混淆视听：OpenCL 1.0可以很好地使用双浮点，这是所有制造商都支持的 "公共选项"--但不是针对所有旧地图。
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
"可选双精度和半浮点
OpenCL 1.0增加了对双精度和半浮点的支持，作为可选的扩展。双重 数据类型必须确认为IEEE-754双精度存储格式。
想要使用双 精度的应用程序需要在内核代码中声明任何双精度数据类型之前加入#pragma OPENCL EXTENSION cl_khr_fp64 : enable 指令。这将扩展内置矢量和标量数据类型的列表，包括以下内容：....."。
它可以在策略测试器中工作，但在OpenCL 1.0专家顾问中不能工作，不是因为如Rinat所说的 "那里没有双浮点"，而是如我已经提到的，因为OpenCL 1.0中没有安全线程，MT4-5中也没有线程。
OpenCL（和CUDA）在总体上是混乱的。你想要什么？毕竟，铁和无线电工程师们着手改变编程的概念。他们有一种铁的心态。
所谓的 "平台选择 " 也会有问题： 程序，即MT或DLL或Expert Advisor，必须，就是必须选择平台（AMD、Nvidia、Intel），这可能是几个不同的平台，将运行OpenCL连接器，然后手动选择DEVICE，如果你的电脑是运行多GPU。OpenCL中的平台自动选择功能还没有出现。Rinat谈到了 "自动选择最强大的"，但我不知道它是怎样的。在那里显示的例子中，没有平台选择，也没有设备选择（GPU、CPU）。
此外，在标准中还没有对多个GPU或GPU+CPU上的任务进行自动OpenCL并行化。让我们这样说吧：在某些版本的驱动/SDK中，AMD曾经引入了这种自动配置，但出现了一些问题，目前AMD已经关闭了这个功能。
一句话：开发和启用OpenCL程序需要一些手工操作，因此不会自动工作或通过 "用选项重新编译"。这在实际操作中又充满了大量的停顿。这将是一项微妙的工作，重要的是，我允许自己重复，不幸的是，这是以犹太人为导向的程序，这是错误的。调试CUDA或OpenCL的并行程序比钢铁革命者假设的要困难得多。Nvidia甚至取消了他们的2011年秋季CUDA会议--由于驱动问题和大量关于停滞调试的投诉。因此，他们在最新的工具包中又 增加了1000个新功能--如果最简单的程序甚至不能运行或运行时出现中断，那该怎么办？毕竟，他们在描述性工具中甚至没有提到OpenCL或CUDA的一半内部机制。
由于驱动或软件的兼容性，悬挂的显卡的GPU速度（单位：GigaFLOPS）为零。
谢谢你，我本人还没有看到。只不过，这并不那么简单。
....这并不是真正的重点。你可以用程序化的方式在五号文件上写作。
joo: 而且 ，我对这一事实感到灰心，阿克纠!-MQL4调用dll的速度比MQL5调用相同dll的速度快...
这就是令人震惊之处。
他们本可以在MQL5中开发对OMP的本地支持。这对编码者来说很容易，也很便宜，而且不需要编写任何dll。
但这群蜜蜂在不完整的铁质编程语言中...还不能完全激发我的兴趣。嗯，是的，在某些情况下百倍加速是很好的，但就编程文化而言，它是一种退步。
在OpenCL（和CUDA）中，一般来说有很多困惑。你想要什么？毕竟，铁和无线电工程师已经着手改变编程的概念。他们有一种铁的心态。
所谓的 "平台选择 " 也会有问题： 程序，即MT或DLL或Expert Advisor，必须，就是必须选择平台（AMD、Nvidia、Intel），这可能是几个不同的平台，将运行OpenCL连接器，然后手动选择DEVICE，如果你的电脑是运行多GPU。OpenCL中的平台自动选择功能还没有出现。Rinat谈到了 "自动选择最强大的"，但我不知道它是怎样的。在那里显示的例子中，没有平台选择，也没有设备选择（GPU、CPU）。
此外，目前还没有标准的方法来自动将OpenCL任务在几个GPU或GPU+CPU之间并行化。让我们这样说吧：在其驱动/SDK的某些版本中，AMD曾经实现了这种自动并行化，但出现了一些问题，迄今为止AMD已经将其关闭。
一句话：开发和启用OpenCL程序需要一些手工操作，因此不会自动工作或通过 "用选项重新编译"。这在实际操作中又充满了大量的停顿。这将是一项微妙的工作，重要的是，我允许自己重复，不幸的是，这是以犹太人为导向的程序，这是错误的。调试CUDA或OpenCL的并行程序比钢铁革命者假设的要困难得多。Nvidia甚至取消了他们的2011年秋季CUDA会议--由于驱动问题和大量关于停滞调试的投诉。因此，他们在最新的工具包中又 增加了1000个新功能--如果最简单的程序甚至不能运行或运行时出现中断，那该怎么办？毕竟，他们在描述性工具中甚至没有提到OpenCL或CUDA的一半内部机制。
由于驱动或软件的兼容性，悬挂的显卡的GPU速度（单位：GigaFLOPS）等于零。
这并不是真正的重点。你也可以在5号文件中以程序化的方式写作。
但这是令人震惊的。
他们本可以在MQL5中开发对OMP的本地支持。这很简单，也很干净，不需要写dll。
但这群蜜蜂在一个不完整的硬件编程语言中.........似乎不是很刺激。是的，在某些情况下，百倍的速度是伟大的，但就编程文化而言，它是一种退步。
我也遇到过mql4比MQL5更快工作的事实。在大多数情况下，它表现为由程序员优化的数学运算。
但我认为这不是主要问题--通过使用OpenCL MQ，他们走上了一条与主要编程路径平行的道路--也许到目前为止，这需要退一步，但在未来的计算机技术发展中，我们将看到集成的可扩展系统，在那里，是使用顺序处理还是并行处理，已经取决于代码了。
所以道路是很正确的。虽然现在没有那么多要求 实施并行方法的算法，但这是因为数学思想没有实施并行计算的设备，因此没有必要创造这种算法。
阿列克谢，想想一个事实，所有的数学发现都是在200-300年前做出的，最近100年的数学思想只是在打磨现有的东西。只有NS的发现才产生了对平行计算的需求。未来100年，将看到大量的平行算法。而你，包括其他人，可以发明其中的一个。
我也看到过mql4比MQL5快的事实。这最常出现在由程序员优化的矩阵运算中。
但我认为这不是主要问题--通过进入OpenCL，MQ已经走上了一条与主要编程道路平行的道路；也许到目前为止，这需要退一步，但在计算机技术的未来发展中，我们将看到集成的可扩展系统，在那里，是使用顺序处理还是并行处理，已经取决于代码了。
所以道路是很正确的。虽然现在没有那么多要求 实施并行方法的算法，但这是因为数学思想没有实施并行计算的设备，因此没有必要创造这种算法。
阿列克谢，只考虑一个事实，所有的数学发现都是在200-300年前完成的，过去100年的数学思想只是在打磨现有的东西。只有NS的发现才形成了对平行计算的需求。未来100年，将看到大量的平行算法。而你，包括其他人，可以发明其中的一个。
不，你毕竟不是完全没有希望。:)
你好。
MQ是好的，他们不怕处理这样的痛苦（对他们来说），如引入对GPU计算的支持。痛苦，首先是与以下事实有关：引进根本性的新技术（任何），一开始就降低了整个平台的可靠性和容错性。但他们完全明白，未来属于并行计算，他们迟早会在这个方向上有所作为（第一步已经迈出--云）。
PS 嗨，尼古拉。你为什么会消失？- 请给我留言。
这不是一个事实，因为它不是。数学的质的发展从未中断过。
而并行计算不仅是NS所需要的，还有更多平凡的任务--比如视频编码或渲染。
但是，MQ运动的总体方向无疑是令人鼓舞的。