测试x64平台的新MQL5编译器--计算速度提高2至10倍 - 页 2

新评论
 
Yury Kulikov:
例如，终端间的通信。

好吧，如果你这样扭曲它，那么当然，DLL是一个有用的功能......

但我个人认为，我并不需要一个DLL。 现在我正在考虑一个EA，它可以从一个经纪公司获取报价并向另一个公司发送信号，而这个公司甚至没有使用MetaTrader。(DucaCopi，顺便说一下，我不知道MetaQuotes是否会同意这个可敬的经纪人？）。

正在考虑DLL的方向。但决定共享文件更安全、更合理。让MetaTrader把信号写到文件中。并让另一个MetaTrader（或JForex或其他人）读取并执行它们。

 

顺便说一下，我一直在思考数组引用的问题...

雷纳特，我提出一个建议。

既然我们有一个标准库，我们是不是应该添加一个OnCalculate()函数的变体，其原型如下。

intOnCalculate(constint rates_total,//输入时间序列的大小)
constint prev_calculated,// 前次调用时处理的条数
const CiTime* ptTime,// 时间
const CiOpen* poOpen,// Open
const CiHigh* phHigh,// High
const CiLow* plLow,// Low
const CiClose* pcClose,// 关闭
const CiTickVolume* ptvTickVolume,// Tick Volume
const CiRealVolume* prvRealVolume,// Real Volume
const CiSpread* psSpread// Spread
);

?

在我看来，这需要对MetaTrader进行非常小的改动，但另一方面，它只是提供了数组的指针，可以在不复制的情况下传递给处理类。而标准库的概念本身也得到了普及。

 

在真正的大项目（约2万行源代码）的例子中，得到了比较新旧编译器性能的第一个结果。

用旧版编译器编译的程序的运行时间结果（4次运行）。

2015.05.02 13:48:46.641 *** (EURUSD,D1)       Start ***. Parsing of history deals (22575) and orders (22656) completed in 6.443 sec. 116 MB RAM used.
2015.05.02 13:48:27.879 *** (EURUSD,D1)       Start ***. Parsing of history deals (22575) and orders (22656) completed in 6.427 sec. 116 MB RAM used.
2015.05.02 13:48:12.067 *** (EURUSD,D1)       Start ***. Parsing of history deals (22575) and orders (22656) completed in 6.287 sec. 116 MB RAM used.
2015.05.02 13:47:49.719 *** (EURUSD,D1)       Start ***. Parsing of history deals (22575) and orders (22656) completed in 8.751 sec. 116 MB RAM used.

用新编译器版本编译的程序的运行时间结果（4次运行）。

2015.05.02 13:54:18.638 *** (EURUSD,D1) Start ***. Parsing of history deals (22575) and orders (22656) completed in 5.475 sec. 116 MB RAM used.
2015.05.02 13:54:01.995 *** (EURUSD,D1) Start ***. Parsing of history deals (22575) and orders (22656) completed in 5.616 sec. 116 MB RAM used.
2015.05.02 13:53:43.853 *** (EURUSD,D1) Start ***. Parsing of history deals (22575) and orders (22656) completed in 5.444 sec. 116 MB RAM used.
2015.05.02 13:53:25.809 *** (EURUSD,D1) Start ***. Parsing of history deals (22575) and orders (22656) completed in 6.147 sec. 116 MB RAM used.

*程序的第二次和下一次运行是在预热缓存的情况下进行的--正如我们看到的，预热缓存提高了15-30%的生产率。

正如你所看到的，新编译器的结果更好：在第一次运行中，解析超过20000个交易和订单需要~6.4秒，在第二次运行中需要~5.4秒，也就是说，性能提高了15-20%。

性能的提高本可以更大，但大部分时间都被系统函数调用占用了。

 

新的编译器在该项目 中没有检测到任何错误，该项目 总共有2万多行的源代码。考虑到这个项目是为旧版本的编译器创建的，这是一个很好的结果。

然而，新的编译器产生了几个与不正确显示文件路径有关的警告信息（斜线转义要求）。

这是一个公平的要求，只要稍加修改就能轻松满足。

因此，我们可以得出结论，即使是用MQL5编写的大型项目，也已经为新的编译器做好了准备，对于专业开发人员来说，切换到新的编译器不会是一个问题。

 
Sergey Eremin:
...
我得到"代码生成错误11"。

...

我也得到这个错误。
 
主要的收获是在数学和你自己的计算上。

如果大部分的艰苦工作是在系统调用中，那么加速将是很小的。
 
Renat Fatkhullin:
主要收获是在数学和自己的计算上。

如果大部分的艰苦工作是在系统调用中，那么加速将是很小的。

它仍然很好，因为你可以用最少的系统函数调用来创建你自己的环境。

(在你的班级中复制一次环境并直接使用它）。

 
George Merts:

好吧，如果你这样扭曲它，那么当然，DLL是一个有用的功能......

但我个人认为，我并不需要一个DLL。 现在我正在考虑一个EA，它可以从一个经纪公司获取报价并向另一个公司发送信号，而这个公司甚至没有使用MetaTrader。(DucaCopi，顺便说一下，我不知道MetaQuotes是否会同意这个可敬的经纪人？）。

想到了dll。但我已经决定，使用共享文件更安全、更合理。让MetaTrader把信号写到文件中。而另一个MetaTrader（或JForex，或其他人）--让他们阅读和执行。

有一个带有命名通道 的选项，但需要一个中间服务器。

论坛上有关于如何做到这一点的例子。

 
Yury Kulikov:
例如，终端间的通信。

亚历山大-布里兹加洛夫。

有一个带有命名通道 的选项，但你需要一个中间服务器。

论坛上有关于如何做到这一点的例子。

不需要任何命名的频道!我们正在等待SQL支持的加入。通过一个表格交换数据。SQL是对多线程、高负担系统的内置支持。
 
Vasiliy Sokolov:

不需要任何命名的频道!等待添加SQL支持。通过一个表来交换数据。SQL是对多线程高负载系统的内置支持。
我只是在谈论我们所拥有的，如果我们增加了sql，我们也可以谈论它 )
123456789...22
新评论