Discussion of article "Speed Up Calculations with the MQL5 Cloud Network" - page 5

 
litechat:

But it would be cool if the indicator was calculated in Cloud Network in real time, I am a programmer myself and I think it can be done.

In principle, nothing prevents you from calculating anything through the second MT5, which is running next to it and connected to Cloud.

Another question is that they are, as it were, vegetable gardens.

If there is support for optimisation (including via claud) directly in MQL5, it will be just great.

We have been asking for this for a long time. I don't remember what the developers replied.

 
komposter:

In principle, there is nothing stopping you from reading anything through the second MT5, which is running next to it and connected to the claude.

At the moment it is done so, 2 computers work together on each of them all cores are used.

If I will be richer I will buy 100 computers, but on the other hand it would be cool to buy agents in Cloud Network that could count indicators or experts.

 
litechat:

At the moment it is done, 2 computers work together on each computer using all cores.

If I will be richer I will buy 100 computers, but on the other hand it would be cool to buy agents in Cloud Network that could read indicators or experts.

Describe in general words, what kind of tasks do you solve for the indicator?

We have a plan to launch the task of background optimisation (basically any calculations) directly from MQL5, which will allow us to make auto-optimised Expert Advisors/indicators. But so far there is no obvious demand, so the idea has stalled.

 
Renat:

Describe in general terms what kind of tasks you are solving for the indicator?

We have a plan to launch the task of background optimisation (basically any calculations) directly from MQL5, which will allow us to make auto-optimised Expert Advisors/indicators. But while there is no obvious demand, the idea has stalled.

In general words:

-- Oncalculate is launched for every tick + I launch every 1 second if there are no ticks by timer (passing arrays of the last tick)

-- Inside Oncalculate I run many cyclic calculations (in calculations I use arrays overridden in Oncalculate) results of calculations are located in indicator buffers, which is the indicator curve, Oncalculate call processing time is not more than 900 milliseconds (in case there are no ticks), I leave 100 milliseconds to the terminal for drawing and for its other needs (ChartRedraw doesn't help, I didn't try to figure out why).

What I would like:
-- that for example Oncalculate with input parameters would work in several agents and their result would be somehow received and used in the indicator, for example inside some new function OnResultAgent, the first thing that came to mind. I'm sure you know better than me how to organise it correctly.

 

Wouldn't algorithmic optimisation help?

There's probably a huge amount of irrational/repetitive/unoptimised calculations in there.

 

Each calculation cycle is unique, the more I have time to calculate the more accurate the forecast is, that's why additional performance is required.

 

the code has been optimised for a long time,

 
Renat:

Wouldn't algorithmic optimisation help?

There must be a huge amount of irrational/repetitive/unoptimised calculations in there.

Convinced, delusional idea, cheaper to buy computers.
 
litechat:

At the moment it is done, 2 computers work together on each computer using all cores.

If I will be richer I will buy 100 computers, but on the other hand it would be cool to buy agents in Cloud Network that could count indicators or experts.

You don't need 2 computers.

You need 2 terminals: one with an indicator, and the second - connected to the Cloud - with a calculating Expert Advisor.

But this option would be suitable if the calculations take at least a couple of minutes (better - a couple of tens of minutes), otherwise the entire advantage will be eaten up by running the terminal in the optimisation mode.

 

I read the comments, some people write that in cloud network genetic optimisation will be slower than regular brute force optimisation.

Who is right?