Optimisation in the Strategy Tester - page 16

New comment
 
Renat:

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:

  • reduction of system overhead in preparation for passes
  • adding an explicit "math calculations" mode to the simulation type selection that has simplified the setup

Again with the same hardware (4 local agents) and clean caches in the 425 build: 

Tester	optimization passed in 0 minutes 07 seconds
Tester	genetic optimization finished on pass 19456 (of 100000020000001)
Tester	result cache was used 10124 times
Tester	genetics is over

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.

if(!ChartGetDouble(0,CHART_PRICE_MAX,0,price_max))
 {
  printf(__FUNCTION__,": Не получены данные по максимальной цене. Ошибка: %g.",GetLastError());
 }

The same situation happens with

if(!ChartGetDouble(0,CHART_PRICE_MIN,0,price_min))
 {
  printf(__FUNCTION__,": Не получены данные по минимальной цене. Ошибка: %g.",GetLastError());
 }
 
slyusar:

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 modeled during testing because it dramatically reduces test speed.
 
Renat:
Charts and graphical objects are not modelled during testing, as this catastrophically reduces the speed of testing.
I see, thank you. Is there any way out of this situation?
 
Renat:
Charts and graphical objects are not modelled during testing, as this catastrophically reduces the speed of testing.
I really hope that this kind of simulation with no graphics will only be in mode without "visualisation".
 
sergeev:
I really hope that this kind of modelling with no graphics will only be in a mode without "visualisation".
Fully supportive, graphics are sometimes very much needed...
 
Renat:

Going back to the old task of optimising the trading strategy tester.

Improvements to the overall plan for the 425 build resulted in:

  • reduction of system overhead in preparation for passes
  • addition of the explicit "math calculations" mode in the simulation type selection, which has simplified the setup

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.

 
We will deal with the parameters after running the test visualiser.
 
joo:

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.

I support you.
Renat:
We will deal with parameters after the start of the test visualizer.
Thank you! We will wait.
 
Renat:

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:

1...910111213141516171819
New comment
Reason: