评估CPU内核的优化
Aleksey Vyazmikin:
我建议收集不同处理器性能的统计数据，以估计它们的效率，以便策略测试器在优化模式下工作。
好的倡议，我支持它。
编译时我得到一个警告。
implicit conversion from 'number' to 'string' Tree_Brut_TestPL.mq5 2567 16
它应该是这样的吗？
字符串。
if(FrameAdd(Test_P,1,0,stat_values)==false)
Aleksey Vyazmikin:
你应该在什么时期进行优化，在什么时间范围内进行优化？这个工具重要吗？
我建议收集各种处理器性能的统计数据，以估计它们在优化模式下对策略测试器的有效性。
为了更加客观，我建议使用在"数学计算"模式下运行的专家顾问，这可以使你最大限度地减少对计算机硬盘和内存的使用。如果可能的话，请说明处理器的名称、主板和内存的频率。
专家顾问只有一个参数需要优化（事实上，它没有什么，而且所有代理的数据都是相同的--要客观），指定等于线程数的通道数，并按处理器核心数选择代理（没有过度训练！）。
我希望收集到的数据能帮助人们选择优化的硬件，这是有道理的，采取的不是第一顺序，至少最近是这样的，但有些事情可能已经改变了。
专家顾问本身是一个真正的EA的剪影，我在一个类似的任务中使用，从决策树中选择叶子，也就是说，这是一个真正的国防部任务，如果有任何想法，如何加快代码，我将非常有兴趣听到它们。代码中只有1000片叶子，实际上已经超过7万片了，所以把它们放到一个函数中，以达到可接受的编译时预期。
Serhii Shevchuk:
好的倡议，我支持它。
它在编译时给出了一个警告。
这是它应该有的样子吗？
行。
纠正并重新启动!
测试一下。
Maxim Romanov:
在什么时期进行优化，在什么时间范围内进行优化？这个工具重要吗？
在什么时期进行优化，在什么时间范围内进行优化？这个工具重要吗？
在数学计算 模式下，这并不重要，那里不会产生刻度线。
那怎么办？2000年代末的树桩不再起飞了吗？:D
Artem Prischepa:
外面有什么？2000年末的树桩不再起飞了吗？:D
外面有什么？2000年末的树桩不再起飞了吗？:D
试用你的处理器并公布你的结果--看看它是起飞了还是只是滚动了!
一匹老马会不会毁了这条沟？
结果。
2019.08.09 23:22:07.472 Tester set "Custom max" as optimization criterion for mathematical calculations 2019.08.09 23:22:07.540 Experts optimization frame expert Tree_Brut_TestPL (EURUSD.m,H1) processing started 2019.08.09 23:22:07.592 Tester cache file 'tester\cache\Tree_Brut_TestPL.30.DFF2DB61B8A3751199D61AD0A0F226D3.opt' deleted 2019.08.09 23:22:07.623 Tester Experts\Tree_Brut_TestPL.ex5 math calculations test means no history and no symbol info for EURUSD.m 2019.08.09 23:22:07.623 Tester complete optimization started 2019.08.09 23:22:07.648 Core 1 agent process started on 127.0.0.1:3008 2019.08.09 23:22:07.650 Core 2 agent process started on 127.0.0.1:3009 2019.08.09 23:22:07.652 Core 3 agent process started on 127.0.0.1:3010 2019.08.09 23:22:07.654 Core 4 agent process started on 127.0.0.1:3011 2019.08.09 23:22:07.657 Core 5 agent process started on 127.0.0.1:3012 2019.08.09 23:22:07.659 Core 6 agent process started on 127.0.0.1:3013 2019.08.09 23:22:07.662 Core 7 agent process started on 127.0.0.1:3014 2019.08.09 23:22:07.664 Core 8 agent process started on 127.0.0.1:3015 2019.08.09 23:22:07.972 Core 1 connecting to 127.0.0.1:3008 2019.08.09 23:22:07.973 Core 1 connected 2019.08.09 23:22:07.983 Core 1 authorized (agent build 2097) 2019.08.09 23:22:07.997 Core 1 common synchronization completed 2019.08.09 23:22:08.035 Core 3 connecting to 127.0.0.1:3010 2019.08.09 23:22:08.036 Core 3 connected 2019.08.09 23:22:08.046 Core 3 authorized (agent build 2097) 2019.08.09 23:22:08.056 Core 2 connecting to 127.0.0.1:3009 2019.08.09 23:22:08.057 Core 2 connected 2019.08.09 23:22:08.059 Core 3 common synchronization completed 2019.08.09 23:22:08.067 Core 5 connecting to 127.0.0.1:3012 2019.08.09 23:22:08.068 Core 5 connected 2019.08.09 23:22:08.068 Core 2 authorized (agent build 2097) 2019.08.09 23:22:08.082 Core 2 common synchronization completed 2019.08.09 23:22:08.083 Core 5 authorized (agent build 2097) 2019.08.09 23:22:08.103 Core 7 connecting to 127.0.0.1:3014 2019.08.09 23:22:08.104 Core 7 connected 2019.08.09 23:22:08.119 Core 7 authorized (agent build 2097) 2019.08.09 23:22:08.125 Core 5 common synchronization completed 2019.08.09 23:22:08.140 Core 7 common synchronization completed 2019.08.09 23:22:08.150 Core 4 connecting to 127.0.0.1:3011 2019.08.09 23:22:08.151 Core 4 connected 2019.08.09 23:22:08.151 Core 8 connecting to 127.0.0.1:3015 2019.08.09 23:22:08.151 Core 8 connected 2019.08.09 23:22:08.162 Core 8 authorized (agent build 2097) 2019.08.09 23:22:08.164 Core 4 authorized (agent build 2097) 2019.08.09 23:22:08.184 Core 6 connecting to 127.0.0.1:3013 2019.08.09 23:22:08.185 Core 6 connected 2019.08.09 23:22:08.208 Core 6 authorized (agent build 2097) 2019.08.09 23:22:08.228 Core 4 common synchronization completed 2019.08.09 23:22:08.240 Core 6 common synchronization completed 2019.08.09 23:22:08.250 Core 8 common synchronization completed 2019.08.09 23:24:45.931 Tester optimization finished, total passes 8 2019.08.09 23:24:45.941 Statistics optimization done in 2 minutes 38 seconds 2019.08.09 23:24:45.941 Statistics shortest pass 0:02:35.945, longest pass 0:02:37.669, average pass 0:02:37.006 2019.08.09 23:24:45.941 Statistics 8000 frames (3.14 Mb total, 412 bytes per frame) received 2019.08.09 23:24:45.941 Statistics local 8 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%) 2019.08.09 23:24:45.988 Tester 8 new records saved to cache file 'tester\cache\Tree_Brut_TestPL.30.DFF2DB61B8A3751199D61AD0A0F226D3.opt'
终端版本。
2019.08.09 23:20:35.776 Terminal MetaTrader 5 x64 build 2085 started (MetaQuotes Software Corp.) 2019.08.09 23:20:35.778 Terminal Windows 10 (build 17763) x64, IE 11, UAC, AMD FX-8300 Eight-Core Processor , Memory: 17102 / 24574 Mb, Disk: 2407 / 2441 Gb, GMT+2
Serhii Shevchuk:
一匹老马会不会毁了这条沟？
结果。
终端版本。
看起来你有8个代理，而你需要4个，因为FX的FPU只有4个和8个ALU，而且在优化时加载的是FPU。为什么这样--不清楚--对开发者的问题，因为代码主要建立在比较上，但显然浮点计算的消耗占上风，或者说慢了几倍，所以事实证明，有必要设置协处理器的数量，那么1个通道会更快，平均时间会保持不变。
Aleksey Vyazmikin:
请澄清一下。我关闭了4个代理，并设置了要优化的参数，这样我就可以得到4次优化或8次优化？
看来你有8个代理参与，你需要4个，因为FX中的FPU只有4个，8个APU，而且在优化时加载的是FPU。为什么会这样--不清楚--对开发人员来说是个问题，因为代码主要是基于比较的，但显然浮点计算的消耗占了上风或慢了几倍，所以事实证明，有必要精确设置协处理器的数量，那么1个通道将更快，平均时间将大致保持不变。
Serhii Shevchuk:
请澄清一下。我是否禁用4个代理，并将参数设置为优化，以便获得4次优化或8次优化？
请澄清一下。我是否禁用4个代理，并将参数设置为优化，以便获得4次优化或8次优化？
8个通过4个代理，有点类似于超级交易--根据线程的数量。
打开"完整的优化日志"，可以看到每次通过的时间。
我建议收集各种处理器性能的统计数据，以估计它们在优化模式下对策略测试器的有效性。
为了更加客观，我建议使用在"数学计算"模式下运行的专家顾问，这可以使你尽量减少硬盘和电脑内存的使用。如果可能的话，请说明处理器的名称、主板和内存的频率。
专家顾问只有一个参数需要优化（事实上，它没有什么，所有代理的数据都是相同的--为了客观起见），指定相当于线程数的通道数，并通过处理器核心数来选择代理（没有超突击！）。
我希望收集到的数据能帮助人们选择优化的硬件，这是有道理的，采取的不是第一顺序，至少最近是这样的，但有些事情可能已经改变了。
专家顾问本身是一个真正的EA的剪影，我在一个类似的任务中使用，从决策树中选择叶子，也就是说，这是一个真正的国防部任务，如果有任何想法，如何加快代码，我将非常有兴趣听到它们。代码中只有1000片叶子，实际上已经有7万多片了，所以它们被放入一个函数中，为编译结果争取可接受的等待时间。
在策略测试器的日志中，通过上下文菜单，勾选 "全面优化日志 "选项。补充：在这个主题中，结果发现在一些（这个有待发现）处理器中的文件大小会影响整个系统的性能，尽管代码在结构上没有什么变化。因此，我要求大家测试两个测试者。
测试者设置的例子 - 符号、周期和时间框架并不重要 - 其他设置是相关的。 截图显示了另一个EA，但设置是正确的
到目前为止，我们有以下评级，其中使用了以秒为单位的平均时间--最后两列，最后一列显示了1小时内处理器的通过次数。
该表由最后一列过滤，作为计算资源 消耗方面最重的EA选项。