MT5和速度在行动 - 页 71 1...646566676869707172737475767778...94 新评论 Roman 2020.11.05 09:06 #701 fxsaber:我建议，这就是理论研究的结束，它永远不会与这里的实践相交。 那么我建议你也停止那些无意义的单线程同步测试。 期待得到平行的结果。 Aleksey Nikolayev 2020.11.05 09:07 #702 fxsaber:这个问题没有得到任何解决。如果内部变量，例如，从不同的线程读/写访问，MQL程序将变得更加复杂的数量级。 只是，MQL6应该类似于Erlang，而不是C++ ) fxsaber 2020.11.05 09:09 #703 Roman:那么我建议你也停止那些无意义的单线程同步测试。 期待得到平行的结果。 我担心的是，几乎每一个刻度 都会出现大的滞后。这与线程无关。开发者们正在摸索。 Igor Makanu 2020.11.05 09:13 #704 Aleksey Nikolayev:只是，MQL6应该类似于Erlang，而不是C++ ) 那么Scala会更好。 ....但不管你怎么看，在这些带有动态类型的强函数式语言 的包装后面...仍将是机器C++，Python就是一个证明，所讨论的带有事件循环的java来自另一个星系，在那里你需要有一个分布式多处理器系统来获得某种扩展和计算系统的可伸缩性。 在学校。 - 沃夫奇卡，你是如何使用鸡毛的？ - 我不知道。 - 那么，你睡在什么上面？ - 在地板上。 - 那你把你的头放在什么上面？ - 在毡靴上。 - 那么你的父母睡在什么上面呢？ - 在地板上。 - 那他们把头放在什么上面呢？ - 关于瓦伦基。 - 那么奶奶睡在什么上面呢？ - 在炉子上。 - 那她把头放在什么上面呢？ - 在一个枕头上。 - 而在枕头里，绒毛是什么？ - 而在枕头里是一个瓦伦基。 Roman 2020.11.05 09:53 #705 Igor Makanu:Scala是更好的，那么....但不管你怎么看，在这些带有动态类型的强函数式语言 的包装后面...Python就是一个证明，所讨论的带有事件循环的java来自另一个星系，在那里你必须有一个分布式多处理器系统来获得计算系统的某种扩展性和可伸缩性。 问题就在这里，Python是用C语言编写的，Python有一个asyncio库，它是基于事件循环模型的。 这么说来，这桩桩件件的奇闻轶事都是真的了)) Aleksey Nikolayev 2020.11.05 10:00 #706 Igor Makanu:那么Scala会更好。 最主要的是用VHDL编译并制作自己的服务器) Sergei Lebedev 2020.11.05 17:27 #707 讨论在某个地方走偏了--与Python的整合速度当然是一个重要的问题，但有许多基本问题影响了EA的执行速度。 我建议关注的问题是，在OnTradeTransaction函数 中最后调用TRADE_TRANSACTION_HISTORY_ADD时，MqlTradeTransaction和MqlTradeResult结构的字段几乎是空的，也就是说，它们没有按照订单随后反映在历史标签中的方式以及在帮助/文件中的归档方式进行类比填充。对这一缺陷的修正已经给战斗的执行带来了真正的加速，因为不需要再不必要地调用HistoryOrderSelect来获得关于已执行订单的综合值。 而从整体上看，在Mql社区层面上，这一差距的消除将导致大量减少在专家顾问中创建不同的拐杖以绕过OnTradeTransactio当前实施的缺点所需的努力。 问题是如何影响MQ团队？ 也许可以单独发一个帖子，为消除这个功能的缺陷进行投票和收集签名？ fxsaber 2020.11.05 18:18 #708 Sergey Lebedev:问题是如何影响MQ开发团队？ 我的配方似乎是有效的：用简洁的代码再现问题。 Roman 2020.11.05 22:50 #709 Sergey Lebedev:讨论在某个地方走偏了--与Python的整合速度当然是一个重要的问题，但有许多基本问题影响了EA的执行速度。我建议关注的问题是，在OnTradeTransaction函数 中最后调用TRADE_TRANSACTION_HISTORY_ADD时，MqlTradeTransaction和MqlTradeResult结构的字段几乎是空的，也就是说，它们没有按照订单随后反映在历史标签中的方式以及在帮助/文件中的归档方式进行类比填充。对这一缺陷的修正已经给战斗的执行带来了真正的加速，因为不需要再不必要地调用HistoryOrderSelect来获得关于已执行订单的综合值。而从整体上看，在Mql社区层面上，这一差距的消除将导致大量减少在专家顾问系统中创建不同的拐杖以绕过OnTradeTransactio当前实施的缺陷所需的努力。问题是如何影响MQ团队？ 也许可以单独发一个帖子，为消除这个功能的缺陷进行投票和收集签名？不理解Python的例子，说明对异步的讨论总体上缺乏理解。 Python 是事件驱动模型的一个好例子。而伊戈尔的轶事正好说到了点子上。 而如果开发者已经掌握了这个例子的含义，那么他就知道该在哪里挖掘。 任何对及时结果的期望迟早都是建立在同步执行模式上的。 在mql它已经来了。该语言的可能性非常丰富，但被人为地限制在同步执行上。 Andrei Trukhanovich 2020.11.05 23:13 #710 Roman: Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом. 你才是不明白的人，别把话题弄得太乱。 1...646566676869707172737475767778...94 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我建议，这就是理论研究的结束，它永远不会与这里的实践相交。
那么我建议你也停止那些无意义的单线程同步测试。
期待得到平行的结果。
这个问题没有得到任何解决。如果内部变量，例如，从不同的线程读/写访问，MQL程序将变得更加复杂的数量级。
只是，MQL6应该类似于Erlang，而不是C++ )
那么我建议你也停止那些无意义的单线程同步测试。
期待得到平行的结果。
我担心的是，几乎每一个刻度 都会出现大的滞后。这与线程无关。开发者们正在摸索。
只是，MQL6应该类似于Erlang，而不是C++ )
那么Scala会更好。
....但不管你怎么看，在这些带有动态类型的强函数式语言 的包装后面...仍将是机器C++，Python就是一个证明，所讨论的带有事件循环的java来自另一个星系，在那里你需要有一个分布式多处理器系统来获得某种扩展和计算系统的可伸缩性。
在学校。
- 沃夫奇卡，你是如何使用鸡毛的？
- 我不知道。
- 那么，你睡在什么上面？
- 在地板上。
- 那你把你的头放在什么上面？
- 在毡靴上。
- 那么你的父母睡在什么上面呢？
- 在地板上。
- 那他们把头放在什么上面呢？
- 关于瓦伦基。
- 那么奶奶睡在什么上面呢？
- 在炉子上。
- 那她把头放在什么上面呢？
- 在一个枕头上。
- 而在枕头里，绒毛是什么？
- 而在枕头里是一个瓦伦基。
Scala是更好的，那么
....但不管你怎么看，在这些带有动态类型的强函数式语言 的包装后面...Python就是一个证明，所讨论的带有事件循环的java来自另一个星系，在那里你必须有一个分布式多处理器系统来获得计算系统的某种扩展性和可伸缩性。
问题就在这里，Python是用C语言编写的，Python有一个asyncio库，它是基于事件循环模型的。
这么说来，这桩桩件件的奇闻轶事都是真的了))
那么Scala会更好。
最主要的是用VHDL编译并制作自己的服务器)
讨论在某个地方走偏了--与Python的整合速度当然是一个重要的问题，但有许多基本问题影响了EA的执行速度。
我建议关注的问题是，在OnTradeTransaction函数 中最后调用TRADE_TRANSACTION_HISTORY_ADD时，MqlTradeTransaction和MqlTradeResult结构的字段几乎是空的，也就是说，它们没有按照订单随后反映在历史标签中的方式以及在帮助/文件中的归档方式进行类比填充。对这一缺陷的修正已经给战斗的执行带来了真正的加速，因为不需要再不必要地调用HistoryOrderSelect来获得关于已执行订单的综合值。
而从整体上看，在Mql社区层面上，这一差距的消除将导致大量减少在专家顾问中创建不同的拐杖以绕过OnTradeTransactio当前实施的缺点所需的努力。
问题是如何影响MQ团队？ 也许可以单独发一个帖子，为消除这个功能的缺陷进行投票和收集签名？
问题是如何影响MQ开发团队？
我的配方似乎是有效的：用简洁的代码再现问题。
讨论在某个地方走偏了--与Python的整合速度当然是一个重要的问题，但有许多基本问题影响了EA的执行速度。
我建议关注的问题是，在OnTradeTransaction函数 中最后调用TRADE_TRANSACTION_HISTORY_ADD时，MqlTradeTransaction和MqlTradeResult结构的字段几乎是空的，也就是说，它们没有按照订单随后反映在历史标签中的方式以及在帮助/文件中的归档方式进行类比填充。对这一缺陷的修正已经给战斗的执行带来了真正的加速，因为不需要再不必要地调用HistoryOrderSelect来获得关于已执行订单的综合值。
而从整体上看，在Mql社区层面上，这一差距的消除将导致大量减少在专家顾问系统中创建不同的拐杖以绕过OnTradeTransactio当前实施的缺陷所需的努力。
问题是如何影响MQ团队？ 也许可以单独发一个帖子，为消除这个功能的缺陷进行投票和收集签名？
Python 是事件驱动模型的一个好例子。而伊戈尔的轶事正好说到了点子上。
而如果开发者已经掌握了这个例子的含义，那么他就知道该在哪里挖掘。
任何对及时结果的期望迟早都是建立在同步执行模式上的。
在mql它已经来了。该语言的可能性非常丰富，但被人为地限制在同步执行上。
Roman:
Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом.
你才是不明白的人，别把话题弄得太乱。