Optimisation in the Strategy Tester - page 8
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
Now the test run on the above example has a system overhead of about 1.5 seconds at startup to prepare all data (authorisation and synchronisation of calculation data). The point is that the test agents are completely independent and decoupled from the terminal, which leads to the need to fully transfer and synchronise all the data used.
We can't say that the genetic optimizer or tester is slow at superfast calculations within several seconds as the system overhead has a serious influence on the final calculation time. In long calculations of 20 seconds or more per run, the impact of the system overhead is reduced to negligible values.
With each build we reduce this time by caching most of the data directly in the agents. I think we will solve this issue soon.
GA from joo is already faster than the standard one, and when transferring the code to CPP by Studio 10 (adapted to multi-core CPUs) the acceleration is another 6 times faster.
It is without market environment that one can arrange a custom speed calculator for a specific task.
But when trying to make a universal trading engine with on-demand provision of any multi-currency poti data with automatic calculation of profits/limits and reports, the speed will immediately fall by 2-3-4 orders of magnitude.
Now running tests on the above example has a system overhead of about 1.5 seconds at the start to prepare all the data (authorization and synchronization of calculation data). The point is that the test agents are completely independent and decoupled from the terminal, which leads to the need to fully transfer and synchronise all the data used.
We can't say that the genetic optimizer or tester is slow at superfast calculations within several seconds as the system overhead has a serious influence on the final calculation time. In long calculations of 20 seconds or more per run, the impact of the system overhead is reduced to negligible values.
With each build we reduce this time by caching most of the data directly in the agents. I think we'll solve this issue soon.
Without a market environment, it's possible to set up a custom rapid-fire counter for a specific task.
But when trying to make a universal trading engine with on-demand provision of any multicurrency data with automatic profit/limit calculation and reporting, the speed will immediately drop by 2-3-4 orders of magnitude.
Renat, I don't mean that it takes time to prepare market environment and other unavoidable "brakes", I wrote on the previous page:
Most likely, such a monstrous difference is due to the fact that the tester, in addition to direct calculations FF, need to write logs, display information, etc., that is present "enforced braking"
2010.11.28 17:38:30 Core 1 genetic pass (424, 98130899813578) returned result 48.16 in 2059 ms
2010.11.28 17:38:30 Core 2 genetic pass (426, 990006720) started
2010.11.28 17:38:30 core 2 genetic pass (425, 56291461) returned result 26.67 in 2012 ms
2010.11.28 17:38:28 core 2 genetic pass (425, 56291461) started
2010.11.28 17:38:28 core 2 genetic pass (423, 1510001908) returned result 49.98 in 2028 ms
2010.11.28 17:38:28 core 1 genetic pass (424, 98130899813578) started
2010.11.28 17:38:28 core 1 genetic pass (422, 1668020166802) returned result 48.36 in 2013 ms
2010.11.28 17:38:26 core 2 genetic pass (423, 1510001908) started
2010.11.28 17:38:26 core 2 genetic pass (419, 99260769921339) returned result 49.22 in 1935 ms
2010.11.28 17:38:26 core 1 genetic pass (422, 1668020166802) started
2010.11.28 17:38:26 core 1 genetic pass (418, 32073563420604) returned result 26.13 in 1934 ms
2010.11.28 17:38:24 Tester genetic pass (421, 730000073) found in cache with result 50.00
2010.11.28 17:38:24 Tester genetic pass (420, 2080000208) found in cache with result 50.00
2010.11.28 17:38:24 Core 2 genetic pass (419, 99260769921339) started
2010.11.28 17:38:24 2010/11/28 17:38:24 Core 2 genetic pass (417, 99249619924961) returned result 49.26 in 2059 ms
2010.11.28 17:38:24 core 1 genetic pass (418, 32073563420604) started
2010.11.28 17:38:24 core 1 genetic pass (416, 2479846771) returned result 48.49 in 2309 ms
2010.11.28 17:38:22 core 2 genetic pass (417, 99249619924961) started
That is, it takes more than 2 seconds to calculate the bare FF, and that's while there is no reference to the market environment at all.
The optimizer solves such a simple task as f(x1,x2)=x1*x1+x2*x2 somewhere at the 500th "pass" and keeps trying variants as it has defined more than 1000 variants to be calculated.
And there's no settings to affect the search capabilities of the algorithm, moreover, the limit of 64 optimisable parameters is frustrating.
It is possible to set up a custom speed calculator for a specific task without a market environment.
But when trying to make a universal trading engine with provision of any multicurrency data on demand with automatic calculation of profits/limits and reports, speed will immediately fall by 2-3-4 orders of magnitude.
I'm not going to argue, but it would be good to expand the algorithm's control parameters, such as search exit settings and the number of search parameters.
We here at mql5 are working on algorithms to search for 3000 parameters, and it's not the limit, of course not in binary coding but in continuous plane.
And you still have an SRR in your hands.
I have tried to do it in binary coding, but GA loses in such a case on mql5. Continuous search is good because it itself reduces step at convergence. Plus we don't need resources for coding/decoding. Well, in general we need correct tests, it's too early to say anything for sure.
The genetic optimizer will probably become more customizable + we'll minimize the system overhead.
Thank you very much. This is actually very important, more important than many might think.
And hopefully we'll forget about "Threshold 64" at some point too.
In the new 366 build (out on Monday) we've reduced the system overhead to minimum values.
The genetics expert above now spends between 200 and 300 ms instead of 2 seconds per pass.
Thank you very much. It really is very important, more important than many might think.
And hopefully we'll forget about Threshold 64 at some point, too.
Forget it right now, at 4 parameters down to 8 digits the tester gives a warning that the oversize has exceeded the long length.
So, for needs other than testing EAs, write a custom optimizer.
And 64 parameters are quite enough for optimizing EAs.
Yeah, I read the thread, where only such advisers with so many parameters can be found:)
Yeah, I read the thread, where only such advisers with so many parameters can be found:)