OpenCL：MQL5中的内部实现测试 - 页 4 1234567891011...70 新评论 [删除] 2012.01.31 07:35 #31 WChas: 如果我理解正确，1个GPU就是一个非常强大的药剂？在这种情况下，能否禁用CPU代理（由于其相对于视频的速度较低）？再说一遍：有可能有两个ATI而不交火吗？AMD强烈反对在OpenCL中使用交火，因为在交火中实际上有两个GPU，但驱动程序必须在它们之间分配一个图形工作。相反，对于OpenCL 1.1来说，显卡驱动程序本身还没有办法在两个GPU之间划分一个OpenCL作业（见上文）。nvidia SLI的情况也是如此。 hrenfx 2012.01.31 07:45 #32 OpenCL的加入将如何影响云计算的成本？有GPU的代理的成本将高于没有GPU的代理的成本，因为第一个代理的估计时间将大大缩短？鉴于本地机器上只有一个代理会被赋予一个GPU，事实证明，同一本地机器上的不同代理的成本将是不同的（而且是预先计算的）？ михаил потапыч 2012.01.31 08:22 #33 hrenfx:OpenCL的加入将如何影响云计算的成本？有GPU的代理的成本会不会比没有GPU的代理的成本高，因为第一个代理的计算时间会明显缩短？鉴于本地机器上只有一个代理会被赋予GPU，事实证明，同一本地机器上的不同代理的成本将是不同的（并且是预先计算的）？"当执行一项任务时，测试人员 所做的工作被计算为其PR与所花时间的乘积。" Renat Fatkhullin 2012.01.31 09:26 #34 我对OpenCL 1.0并不感到困惑--在驱动出现严重问题的情况下，你必须真的冒险使用它来做双倍。事实上，终端在检测到旧驱动时，会禁用OpenCL，并显示一条信息，告诉你升级到最新版本。否则，即使在最无害的操作中，挂起也是不可避免的。 默认情况下，终端/代理在启动时根据其功能设置选择最强大的GPU设备。到目前为止，还没有从MQL5中选择设备的想法--这只会使代码复杂化，并导致额外的错误。 ，相反，有一个更美丽的想法，即自动分配每个物理GPU给单独的代理，这将允许充分使用它们的潜力。 hrenfx 2012.01.31 09:29 #35 假设我们有一个EX5（使用OpenCL），在有GPU的代理上的优化速度比没有GPU的快20倍。我们 在云上运行优化。很明显，首先在那些拥有物理GPU的代理上运行优化是最有利的（就所需时间而言）。给予他们大部分的列举选项。这相当于他们的PR高了20倍。但是，在不使用GPU的情况下，他们的PR是一样的。也就是说，需要输入一个新的PR计算，即PR_gpu。Mischek: " 当一项任务被执行时，测试人员所做的工作被计算为其PR与所花时间的乘积。"从这个公式可以看出，如果没有PR_gpu，那么有GPU的云上的所有优化成本将比没有的便宜。不幸的是，引入PR的另一种计算方法--优化的EX5文件的单次测试通过包含了大量的陷阱，由于这些陷阱，不可能普遍使用它。 михаил потапыч 2012.01.31 09:37 #36 hrenfx:从这个公式可以看出，如果没有PR_gpu，那么在有GPU的云上进行整个优化的成本将比没有GPU的便宜。不幸的是，引入另一种PR计算方法--优化后的EX5文件的单次测试通过，包含了大量的缺陷，使其无法普遍使用。不谈细节，我也不知道，如果实际的PR不会被修改，那么用GPU转到云端就没有意义了。另外，如果你引入了一个新的概念，并且你喜欢它)例如，如果你正在引入一个 新的概念，你喜欢这样做，最好立即定义它，或者猜测在这种情况下，它是关于用户方面。 hrenfx 2012.01.31 09:48 #37 目前PR=Const Koef/完成基准任务的时间。优化的成本等于在优化持续的时间内可以计算的基准任务的数量。也就是说，计算的成本不取决于云如何在代理之间分配任务。但最终的优化时间取决于适当的分配，这是最重要的指标。很明显，云按照预先计算的PR的比例将任务分配给代理，以减少计算时间（但不是成本 - CONST）。 Renat Fatkhullin 2012.01.31 09:49 #38 当然，在实际使用GPU时，我们会自动增加PR。但首先我们将在公共测试中发布测试版。 当然，OpenCL任务将首先交给拥有合适GPU的代理。 hrenfx 2012.01.31 10:04 #39 hrenfx:计算的成本并不取决于云如何在代理之间分配任务。不幸的是，引入另一种PR计算方法--对优化的EX5文件进行一次测试运行--包含了大量的隐患，使其无法普遍使用。由于优化器的成本总是恒定的，但它的持续时间强烈地依赖于充分的（对于给定的任务）PR计算，也许我们应该引入优化器在他的EX5代码PR_calculate上输入他的良知。其中，优化者根据其算法的特点，将设置最适合其任务的分布式PR。例如，如果任务是纯粹的计算，PR_calculate中的重点将是数学。如果任务处理大量的数据，重点将放在内存处理速度上。如果GPU被使用了一点 - 在你的PR_calculate中显示。如果在EX5中到处使用GPU - 写一个适当的PR_calculate（适当使用GPU）。在这个计划下，向云端出租电力的人没有任何损失，而使用云端电力的人则有机会大大加快他们的计算速度。如果没有指定PR_calculate，则使用已经接受的通用参考任务。P.S. PR_calculate仅用于分配云中的任务。在成本计算方面，仍然使用相同的老式PR。P.P.S.当然，也有陷阱--PR_calculate需要在所有自由职业者身上预先运行。PR_calculate可能被错误地写入--循环的。因此，对于计算PR_calculate的时间，你也要按照经典的PR方案来收钱。等等。 Renat Fatkhullin 2012.01.31 10:45 #40 hrenfx:由于优化器的成本总是恒定的，但其持续时间在很大程度上取决于PR的充分（对于给定的任务）计算，也许值得引入优化器的良心输入到他的EX5代码PR_calculate。其中，优化者根据其算法的特点，将设置最适合其任务的分布式PR。 不幸的是，当程序员为自己计算PR时，这个选项将不起作用。 1234567891011...70 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
如果我理解正确，1个GPU就是一个非常强大的药剂？在这种情况下，能否禁用CPU代理（由于其相对于视频的速度较低）？再说一遍：有可能有两个ATI而不交火吗？
AMD强烈反对在OpenCL中使用交火，因为在交火中实际上有两个GPU，但驱动程序必须在它们之间分配一个图形工作。相反，对于OpenCL 1.1来说，显卡驱动程序本身还没有办法在两个GPU之间划分一个OpenCL作业（见上文）。
nvidia SLI的情况也是如此。
OpenCL的加入将如何影响云计算的成本？
有GPU的代理的成本将高于没有GPU的代理的成本，因为第一个代理的估计时间将大大缩短？
鉴于本地机器上只有一个代理会被赋予一个GPU，事实证明，同一本地机器上的不同代理的成本将是不同的（而且是预先计算的）？
OpenCL的加入将如何影响云计算的成本？
有GPU的代理的成本会不会比没有GPU的代理的成本高，因为第一个代理的计算时间会明显缩短？
鉴于本地机器上只有一个代理会被赋予GPU，事实证明，同一本地机器上的不同代理的成本将是不同的（并且是预先计算的）？
默认情况下，终端/代理在启动时根据其功能设置选择最强大的GPU设备。到目前为止，还没有从MQL5中选择设备的想法--这只会使代码复杂化，并导致额外的错误。
，相反，有一个更美丽的想法，即自动分配每个物理GPU给单独的代理，这将允许充分使用它们的潜力。
假设我们有一个EX5（使用OpenCL），在有GPU的代理上的优化速度比没有GPU的快20倍。
我们 在云上运行优化。很明显，首先在那些拥有物理GPU的代理上运行优化是最有利的（就所需时间而言）。给予他们大部分的列举选项。这相当于他们的PR高了20倍。但是，在不使用GPU的情况下，他们的PR是一样的。也就是说，需要输入一个新的PR计算，即PR_gpu。
" 当一项任务被执行时，测试人员所做的工作被计算为其PR与所花时间的乘积。"
从这个公式可以看出，如果没有PR_gpu，那么有GPU的云上的所有优化成本将比没有的便宜。
不幸的是，引入PR的另一种计算方法--优化的EX5文件的单次测试通过包含了大量的陷阱，由于这些陷阱，不可能普遍使用它。
从这个公式可以看出，如果没有PR_gpu，那么在有GPU的云上进行整个优化的成本将比没有GPU的便宜。
不幸的是，引入另一种PR计算方法--优化后的EX5文件的单次测试通过，包含了大量的缺陷，使其无法普遍使用。
不谈细节，我也不知道，如果实际的PR不会被修改，那么用GPU转到云端就没有意义了。
另外，如果你引入了一个新的概念，并且你喜欢它)例如，如果你正在引入一个 新的概念，你喜欢这样做，最好立即定义它，或者猜测在这种情况下，它是关于用户方面。
目前PR=Const Koef/完成基准任务的时间。
优化的成本等于在优化持续的时间内可以计算的基准任务的数量。也就是说，计算的成本不取决于云如何在代理之间分配任务。但最终的优化时间取决于适当的分配，这是最重要的指标。
很明显，云按照预先计算的PR的比例将任务分配给代理，以减少计算时间（但不是成本 - CONST）。
当然，OpenCL任务将首先交给拥有合适GPU的代理。
计算的成本并不取决于云如何在代理之间分配任务。
不幸的是，引入另一种PR计算方法--对优化的EX5文件进行一次测试运行--包含了大量的隐患，使其无法普遍使用。
由于优化器的成本总是恒定的，但它的持续时间强烈地依赖于充分的（对于给定的任务）PR计算，也许我们应该引入优化器在他的EX5代码PR_calculate上输入他的良知。其中，优化者根据其算法的特点，将设置最适合其任务的分布式PR。
例如，如果任务是纯粹的计算，PR_calculate中的重点将是数学。
如果任务处理大量的数据，重点将放在内存处理速度上。
如果GPU被使用了一点 - 在你的PR_calculate中显示。
如果在EX5中到处使用GPU - 写一个适当的PR_calculate（适当使用GPU）。
在这个计划下，向云端出租电力的人没有任何损失，而使用云端电力的人则有机会大大加快他们的计算速度。
如果没有指定PR_calculate，则使用已经接受的通用参考任务。
P.S. PR_calculate仅用于分配云中的任务。在成本计算方面，仍然使用相同的老式PR。
P.P.S.当然，也有陷阱--PR_calculate需要在所有自由职业者身上预先运行。PR_calculate可能被错误地写入--循环的。因此，对于计算PR_calculate的时间，你也要按照经典的PR方案来收钱。等等。
由于优化器的成本总是恒定的，但其持续时间在很大程度上取决于PR的充分（对于给定的任务）计算，也许值得引入优化器的良心输入到他的EX5代码PR_calculate。其中，优化者根据其算法的特点，将设置最适合其任务的分布式PR。