You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
In the latest builds, we've gotten rid of system overheads on task runs completely, reducing them from almost 2000 ms to zero.
Here are the results of running a calculation task, which was suggested by joo:
Settings (the dates are set on purpose so that the chart history is not used):
Parameters to be run:
Agents used (4 local agents):
Optimisation results:
Optimisation took only 25 seconds and 18,432 passes were made:
Going back to the old trading strategy tester optimisation task.
Improvements to the general plan for the 425 build resulted in:
Again with the same hardware (4 local agents) and clean caches in the 425 build:
Compared tothe original issue raised(the overhead was 2 sec per pass), we successfully solved the problem. The same task started counting in 7 seconds instead of 25 seconds.
The basis of the fight against system overheads was to batch tasks. Now each agent has its execution speed measured, and a batch of 1-64 tasks has been given to us for calculation. As a result, the time required to prepare tests and get results is proportionally reduced. Fast agents get more tasks and larger batch sizes than slow ones. This is especially beneficial for fast calculation tasks, where useful calculation time is comparable to test preparation and results forwarding time.
The work to optimise agent maintenance is not yet complete. For the efficient work of remote agents in the MQL5 Cloud Network, reducing communication costs is the main issue.
Help to understand!
The following code blocks work fine in the terminal on a demo account, but when tested they give anerror message4109.
The same situation happens with
Help to understand!
The following code blocks work fine in the terminal on a demo account, but when tested they give anerror message4109.
The same situation happens with
Charts and graphical objects are not modelled during testing, as this catastrophically reduces the speed of testing.
Charts and graphical objects are not modelled during testing, as this catastrophically reduces the speed of testing.
I really hope that this kind of modelling with no graphics will only be in a mode without "visualisation".
Going back to the old task of optimising the trading strategy tester.
Improvements to the overall plan for the 425 build resulted in:
Another results on the same hardware (4 local agents) and clean caches in 425 build:
Compared tothe original issue raised(the overhead was 2 sec per pass), we successfully solved the problem. The same task started counting in 7 seconds instead of 25 seconds.
The basis of the fight against system overheads was to batch tasks. Now each agent has its execution speed measured, and a batch of 1-64 tasks has been given to us for calculation. As a result, the time required to prepare tests and get results is proportionally reduced. Fast agents get more tasks and larger batch sizes than slow ones. This is especially effective for fast calculation tasks, where the time of useful calculations is comparable to the time of preparing tests and forwarding results.
The work to optimise agent maintenance is not over yet. For the efficient work of remote agents in the MQL5 Cloud Network, reducing the cost of providing communication is the main issue.
A very serious change for the better - thank you.
What about the limit of 64 parameters? It is the only factor, at least for me, that restrains the full-fledged use of the optimizer. I already want to forget about any fuss and write for the "real" world, so that the tester could be optimized without any changes in the code.
A very serious change for improvement - thank you.
What about the 64 parameter limit? It's the only factor, at least for me, that restrains full-scale use of the optimizer. And how I want to forget about all that fuss and write for "real" code at once so that I could optimize it in the tester without any changes in the code.
We will deal with parameters after the start of the test visualizer.
Going back to the old problem of optimising the trading strategy tester.
Next results on the same hardware (4 local agents) and clean caches in 425 build:
Compared tothe original issue raised(the overhead was 2 seconds per pass), we have successfully solved the problem. The same problem is now 7 seconds instead of 25 seconds.
In the next build to be released we have done a lot of work to optimize bulk computation of mathematical problems. System overheads have been reduced to zero.
Now the same problem with the same hardware (Intel Q9400, 4 local cores) for ~18 000 calculations takes 1 second (last time it was 7 seconds, while before it took 25 seconds):
2011.04.04 20:12:34 Tester optimization passed in 0 minutes 01 seconds
2011.04.04 20:12:34 Tester genetic optimization finished on pass 18432 (of 1000000002000000001)
2011.04.04 20:12:34 Tester result cache was used 9718 times
2011.04.04 20:12:34 Tester genetics is over
For comparison I can show how much time on the same hardware the same mathematical task spends to calculate 4 million passes (by reducing the step to 0.005 the total number of calculations became 4 million, which allows to run a full calculation):
2011.04.04 20:10:34 Tester optimization passed in 0 minutes 46 seconds
2011.04.04 20:10:34 Tester optimization finished, total passes 4004001
In 46 seconds the full miscalculation of 4 million tasks takes place, the optimization results window shows all 4 million rows with results, the whole table is instantly sorted on any fields, the optimization graph is briskly rendering all 4 million values, the 3D graph is drawing a 3D surface from the same results and spinning it in different angles: