OpenCL: internal implementation tests in MQL5 - page 17
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
However, there is still a fleet of videocards that do not support GPU calculations and it is for them that OpenCL code calculation emulation on the CPU is done (which, as you can imagine, will be much slower).
Software OpenCL has nothing to do with video cards and does not include any of the partial functions of older cards. It is pure CPU execution.
OpenCL software has nothing to do with video cards and does not include any partial features of older cards. It is pure CPU execution.
That's exactly what I wanted to convey, thank you for clarifying.
Yes, exceptions are written in C++ where the choice is made as to whether the OpenCL code will be executed on the GPU device or CPU, but this exception is written only when the GPU cannot be used. There are no tests to see which CPU or GPU is faster for a certain code. This needs to be understood.
A serious struggle for speed is unfolding, hence the question: what is good code and what is bad code? What are the things that take away speed? Would you recommend something to read?
By the way, we are preparing a new mechanism of working with caches of intermediate bar states for the tester, which will give a serious acceleration in optimization of trading robots.
It will be released in the next builds after long tests.
There's also an interesting question: what is the meaning of life?
It's unequivocally to servicedesk !!!! )))
I once observed a similar scene:
A deaf grandmother walks up to her grandson and points her finger at a CD-ROM and asks a question:
- Is that a tape there? A movie?
The grandson's face displays the process of scanning information about computers, CD drives, coding information as 0 and 1, CDFS, FAT32, recording video information in avi format, and after frantic brain work, the answer comes:
- grandma I'm not going to answer you.
By the way, we are preparing a new mechanism of working with caches of intermediate bar states for the tester, which will give a serious acceleration in optimization of trading robots.
It will be released in the next builds after long tests.
By the way, we are preparing a new mechanism of working with caches of intermediate bar states for the tester, which will give a serious acceleration in the optimization of trading robots.
In the next builds it will be available after long tests.
We are looking forward to it.
Theoretically, if for opening prices, it could be accelerated in this way:
We take two caches: for M1 and for the current timeframe.
We check the current n-th bar using the cache of the current timeframe. If a position opens or closes at the market, then we execute an order at the opening price of the current timeframe. If any of the pending orders (protective stops, i.e. Take Profit or Stop Loss are also pending orders) by the prices of pending orders are in the range: Max(High[0], Close[1]) and Min[Low[0], Close[1]), then we run this bar as for cache M1. If none of the orders have entered the range, the bar is skipped.
How does it look like?
It is too boring to optimize on large timeframes.
Renat, I also left a message in the branch: https://www.mql5.com/ru/forum/4927/page116 on speeding up forward tests in the genetic algorithm mode. I would like to hear the developers' opinion.
Put up Catalyst Centre 12, previously it was 11. Already have results (highlighted in red): ........................