Questions on Coding existing EA in OpenCL
I suppose the task of porting EA (with entire trading logic and technical analysis) into GPU is huge, and will anyway impose more questions on how precise and consistent the resulting thing works in comparison to the built-in tests and to real trading.
I suggest to consider another way - try to compress (make them sparse) the real ticks and test EA on the produced custom symbol instead. Several algorithms are presented in the algotrading book.
Also, other methods of speeding up any EA are worthwhile. For example, profile your code and eliminate bottlenecks, optimize/change analytical algoritms, embed indicators' code (if any) into EA itself, etc.
- www.mql5.com
I suppose the task of porting EA (with entire trading logic and technical analysis) into GPU is huge, and will anyway impose more questions on how precise and consistent the resulting thing works in comparison to the built-in tests and to real trading.
Could you please elaborate on how porting an EA into OpenCL or Cuda would be such a huge task? The author mentioned above does not appear to share your opinion.
I think that it is kind of obvious! OpenCL is a language on its own right, and different to MQL. Not to mention, that you would need to create the "glue" between the two, since OpenCL would not be able to carry out any trade functionality nor access the quote data directly.
Unless your EA is highly calculation intensive, I doubt you would gain much benefit from using OpenCL. I would instead, say that the your speed gains will come from streamlining and refactoring your existing MQL code, which is usually where the problem lies with slow EAs, namely unstructured and inefficient code.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
I have a few EA's that I concider profitable but take immense amounts of time for backtesting in real ticks. Open prices work but sometimes the variance to real ticks is over 40% which make the backtesting results unacceptably unrealiable. The idea is to comission a developer here to "rewrite" the EAs in OpenCl to reduce backtesting times but I don't know whether its worth it.
As I mine XMR on the side, I have a total of 72 Ryzen 9 cores available for backtesting. In a fast genetic algo backtest going back 18 months using real ticks it takes 10496 calculations which takes on average about 22 hours to complete.
On the local machine I have 128GB of ram and it soaks it up to the hilt on every tick data backtests. The machines on the local farm do not have that much RAM so I always need to disable cores not to slow the calculations down due to the machines drawing from disc space.
In this older thread on OpenCL https://www.mql5.com/en/articles/690 it claims up to a 100 fold decrease in calculation times using some GPUs compared to some CPUs at that time. I have plenty of GPUs back from the Ether mining days and tried the Seascape script metioned here https://www.mql5.com/en/forum/445276 and it works fine. So from the hardware/driver perscective I believe I am good to go.
Questions:
1. I have read a few threats on how the OpenCL implementation is either diffucult or not working correctly. Is that still the case?
2. Is MT5 able to use multiple GPUs in the "local network farm" the same way it is able use multiple CPUs?
3. Does anyone have currently running EAs based on OpenCL and if so, could you share how its going?