Discussion of article "Using OpenCL to test candlestick patterns" - page 3

New comment
 

Very interesting article. The main benefit it to see a real example of OpenCL code in action, it's very useful when you start using OpenCL yourself to have such examples. Thanks.

However, while the comparison confirms the expected huge gain using GPUs, it's a very specific strategy, where there is no relation at all between trades. It's probably rare to see such strategy in real trading. I am afraid when you will start to introduce relation between trades (a maximum open trades, only 1 trade at a time, lot increase or decrease after a winner/looser, etc...), the complexity of the OpenCL code will quickly lead to lose the speed gain benefits. (I didn't try it myself so I could be wrong).

Less importantly, for a suitable comparison, the "virtual" algorithm used with GPUs, should also be used without it, it would allow to measure to net gain due to GPUs. As in the article approach, you are not only comparing CPU to GPU (seriel to parallel) but also the "Strategy Tester" to "virtual".

 
Hey there,
is OpenCL still a thing, because word is that AMD seems to not support it any longer?

Is there a workaround, does one need Linux or are there any other GPU-scheduling methoda for parallel computing that are somewhat easily accessible?

Regards
 

Good afternoon.

Can you tell me an approximate way how to achieve the opening of only one transaction at a time to buy and also only one to sell in your code.

 
Sergey Seriy:

Good afternoon.

Can you tell me an approximate way how to achieve the opening of only one transaction at a time to buy and also only one to sell in your code.

Firstly, in the tester_step kernel you need to add one more argument that will allow you to get the time of deal closing (it can be the index of the M1 bar, where the deal closed, or the time of position holding, expressed in the number of M1 bars ) with indexing, as in the __global double *Res result buffer.

Next, depending on whether your question relates to single testing or optimisation:

1. testing. In the loop where the total profit is summarised, you need to add conditions that will exclude overlapping of open positions using closing times (which will be returned by the finalised tester_step).

2. optimisation. Here, instead of the find_patterns_opt kernel, which summarises profits, we need to use find_patterns, which will simply return entry points. Taking into account the conditions of inadmissibility of opening more than one trade at a time, we will have to summarise the profit in the mql5 code. However, it may take some time (you should try it), because in this case what was executed in parallel will be executed sequentially (the number of optimisation passes is multiplied by the depth of optimisation). Another possible compromise option is to add a kernel that will count profit for one pass (taking into account the condition on the number of simultaneously opened positions), but from my own practice I can say that it is a bad idea to run "heavy" kernels. Ideally, one should strive to keep the kernel code as simple as possible and run as many of them as possible.

 
Serhii Shevchuk:

Firstly, in the tester_step kernel we need to add one more argument that will allow us to get the time of closing a trade (it can be the index of bar M1, where the trade closed, or the time of holding a position expressed in the number of bars of M1) with indexing, as in the __global double *Res result buffer.

Further, depending on whether your question refers to single testing or optimisation:

1. testing. In the loop where the total profit is summarised, you need to add conditions that will exclude overlapping of open positions using closing times (which will be returned by the finalised tester_step).

2. optimisation. Here, instead of the find_patterns_opt kernel, which summarises profits, we need to use find_patterns, which will simply return entry points. Taking into account the conditions of inadmissibility of opening more than one trade at a time, we will have to summarise the profit in the mql5 code. However, it may take some time (you should try it), because in this case what was executed in parallel will be executed sequentially (the number of optimisation passes is multiplied by the depth of optimisation). Another possible compromise option is to add a kernel that will count profit for one pass (taking into account the condition on the number of simultaneously opened positions), but from my own practice I can say that it is a bad idea to run "heavy" kernels. Ideally, one should strive to keep the kernel code as simple as possible and run as many of them as possible.

Good afternoon.

Thank you for your quick reply. I was interested first of all in the answer on optimisation, as the idea to apply the code in practice, by the way I thought that partially I will have to write in mql code. Thank you very much for the article, as there is nothing like it! Also if we modify tester_step (and tester_step_opt) a little bit by adding to the time condition p>open to buy (ie. if(j>=maxbar || (TimeM1[j]>=tclose && p>open)) and for selling if(j>=maxbar || (TimeM1[j]>=tclose && p<open))), you will get a strategy for options trading.

 

...I will also add a few words to my previous comment about the option strategy. Here we need to add the Option Expiration Time variable (at the same time StopLoss and TakeProfit are not needed for options during optimisation), so we modify the code in tester_opt_step as follows:

ulong tcloseDEATH=TimeM1[iO]+240*60*60;//add expiry time variable, например 240 часов (т.е. 10 дней)



//...further comment TP and SL as they are not needed for options

/*if(p<=sl)
 {
 Res[idx]=sl-open;
 return;
 }
 else if(p>=tp)
 {
 Res[idx]=tp-open;
 return;
 }*/
// and add a check for expiry time (at expiry of the VE there should be a large LOSS because the option is unsuccessful).
              if(TimeM1[j]>=tcloseDEATH)
              {
               Res[idx]=sl*10-open; //there's a BIG Moose! (для примера в 10 раз больше установленного при оптимизации стоп-лосса)
               return;
              }
 
Good afternoon. When running OpenCL-optimisation for USDRUB according to your article I encountered such a problem - the results of optimisation are always positive, always a profit, i.e. it seems that there is an overflow for a variable of int type, into which the result is generated, while for EURUSD the optimisation works correctly. Perhaps it is also a matter of five digits for USDRUB. Can you tell me how to fix this problem?
 
Sergey Seriy:
Good afternoon. When running OpenCL-optimisation for USDRUB according to your article I encountered such a problem - the results of optimisation are always positive, always a profit, i.e. it seems that there is an overflow for a variable of int type, into which the result is generated, while for EURUSD the optimisation works correctly. Perhaps it is also a matter of five digits for USDRUB. Could you please tell me how to fix this problem?
...also attached screenshots
Files:
example_opt_RES.png  70 kb
example_test_RES.png  73 kb
 

In the article you write:

В нашем случае функция atomic_inc()  для начала запрещает доступ другим задачам к ячейке Count[0], затем увеличивает её значение на единицу, а предыдущее возвращает в виде результата.

As I understand, this function works only with an array of type int, but if I have an array of a different type, for example ushort, what should I do?

123
New comment