Обсуждение статьи "Применение OpenCL для тестирования свечных моделей" - страница 3

 

Очень интересная статья. Главная польза - увидеть реальный пример кода OpenCL в действии, очень полезно, когда начинаешь использовать OpenCL самостоятельно, иметь такие примеры. Спасибо.

Однако, хотя сравнение и подтверждает ожидаемый огромный выигрыш при использовании GPU, это очень специфическая стратегия, где нет вообще никакой связи между сделками. Наверное, редко можно встретить такую стратегию в реальной торговле. Боюсь, что когда вы начнете вводить связь между сделками (максимум открытых сделок, только 1 сделка за раз, увеличение или уменьшение лота после выигрыша/проигрыша и т.д.), то сложность кода OpenCL быстро приведет к потере выигрыша в скорости. (Сам я не пробовал, поэтому могу ошибаться).

Менее важно, что для корректного сравнения "виртуальный" алгоритм, используемый с GPU, должен использоваться и без него, это позволит измерить чистый выигрыш за счет GPU. Как и в случае со статьей, вы сравниваете не только CPU с GPU (последовательный с параллельным), но и"тестер стратегий" с "виртуальным".

 
Привет,
Является ли OpenCL все еще актуальным, потому что, по слухам, AMD больше не поддерживает его?

Есть ли обходной путь, нужен ли Linux или есть ли другие методы планирования GPU для параллельных вычислений, которые в какой-то степени легко доступны?

С уважением,
 

Добрый день.

Подскажите примерный путь как добиться открытия только одной сделки единовременно на покупку и также только одну на продажу в Вашем коде.

 
Sergey Seriy:

Добрый день.

Подскажите примерный путь как добиться открытия только одной сделки единовременно на покупку и также только одну на продажу в Вашем коде.

Во-первых, в кернеле tester_step нужно добавить ещё один аргумент, который позволит получить время закрытия сделки (это может быть индекс бара M1, где сделка закрылась, либо время удержания позиции, выраженное в количестве баров M1) с индексацией, как в буфере результатов __global double *Res.

Далее, в зависимости от того, к чему относится Ваш вопрос - к одиночному тестированию, либо к оптимизации:

1. Тестирование. В цикл, где суммируется общая прибыль, нужно добавить условия, которые будут исключать перекрытие открытых позиций, используя времена закрытия (которые вернёт доработанный tester_step).

2. Оптимизация. Здесь нужно вместо кернела find_patterns_opt, в котором происходит суммирование прибыли, использовать find_patterns, который просто вернёт точки входа. Суммировать прибыль, учитывая условия по недопустимости открытия более одной сделки одновременно, придётся в коде mql5. Правда, это может занять некоторое время (нужно пробовать), так как в этом случае то, что выполнялось параллельно, будет выполнять последовательно (количество проходов оптимизации умножаем на глубину оптимизации). Ещё возможен компромиссный вариант - добавить кернел который будет считать прибыль для одного прохода (учитывая условие по кол-ву одновременно открытых позиций), но из собственной практики скажу, что запускать "тяжелые" кернелы - плохая идея. В идеале нужно стремиться к тому, чтобы код кернела был как можно проще, а запущено их было как можно больше.

 
Serhii Shevchuk:

Во-первых, в кернеле tester_step нужно добавить ещё один аргумент, который позволит получить время закрытия сделки (это может быть индекс бара M1, где сделка закрылась, либо время удержания позиции, выраженное в количестве баров M1) с индексацией, как в буфере результатов __global double *Res.

Далее, в зависимости от того, к чему относится Ваш вопрос - к одиночному тестированию, либо к оптимизации:

1. Тестирование. В цикл, где суммируется общая прибыль, нужно добавить условия, которые будут исключать перекрытие открытых позиций, используя времена закрытия (которые вернёт доработанный tester_step).

2. Оптимизация. Здесь нужно вместо кернела find_patterns_opt, в котором происходит суммирование прибыли, использовать find_patterns, который просто вернёт точки входа. Суммировать прибыль, учитывая условия по недопустимости открытия более одной сделки одновременно, придётся в коде mql5. Правда, это может занять некоторое время (нужно пробовать), так как в этом случае то, что выполнялось параллельно, будет выполнять последовательно (количество проходов оптимизации умножаем на глубину оптимизации). Ещё возможен компромиссный вариант - добавить кернел который будет считать прибыль для одного прохода (учитывая условие по кол-ву одновременно открытых позиций), но из собственной практики скажу, что запускать "тяжелые" кернелы - плохая идея. В идеале нужно стремиться к тому, чтобы код кернела был как можно проще, а запущено их было как можно больше.

Добрый день.

Спасибо за скорый ответ. Интересовал в первую очередь ответ по оптимизации, т.к. идея применять код именно на практике, кстати я сразу так и подумал, что частично придется писать в коде mql. Большое спасибо за статью, т.к. ничего подобного более нет! Также если немного модифицировать tester_step (и tester_step_opt) добавив к условию учета времени p>open для покупки (т.е. if(j>=maxbar || (TimeM1[j]>=tclose && p>open)) и для продажи if(j>=maxbar || (TimeM1[j]>=tclose && p<open))) то получится стратегия для торговли опционами.

 

...также добавлю к предыдущему своему комментарию несколько слов об опционной стратегии. Тут нужно добавить переменную Времени Экспирации опциона (при этом при оптимизации СтопЛосс и ТейкПрофит не нужны для опционов), поэтому модифицируем код в tester_opt_step следующим образом:

ulong tcloseDEATH=TimeM1[iO]+240*60*60;//добавляем  переменную времени экспирации, например 240 часов (т.е. 10 дней)



//...далее комментируем TP и SL т.к. они не нужны для опционов

/*if(p<=sl)
              {
               Res[idx]=sl-open;
               return;
              }
            else if(p>=tp)
              {
               Res[idx]=tp-open;
               return;
              }*/
// и добавляем проверку на  истечение времени экспирации (при истечении ВЭ должен быть большой ЛОСС т.к. опцион неуспешен)
              if(TimeM1[j]>=tcloseDEATH)
              {
               Res[idx]=sl*10-open; //здесь БИГ ЛОСЬ! (для примера в 10 раз больше установленного при оптимизации стоп-лосса)
               return;
              }

 
Добрый день. При запуске OpenCL-оптимизации для USDRUB по вашей статье сталкнулся с такой проблемой - результаты оптимизации всегда положительны, всегда профит, т.е похоже что происходит переполнение для переменной типа int,в которую генерируется результат, при этом для EURUSD оптимизация работает корректно. Возможно также дело в пятизнаке для USDRUB. Подскажите как можно устранить эту проблему?
 
Sergey Seriy:
Добрый день. При запуске OpenCL-оптимизации для USDRUB по вашей статье сталкнулся с такой проблемой - результаты оптимизации всегда положительны, всегда профит, т.е похоже что происходит переполнение для переменной типа int,в которую генерируется результат, при этом для EURUSD оптимизация работает корректно. Возможно также дело в пятизнаке для USDRUB. Подскажите как можно устранить эту проблему?
...также прилагаю скриншоты
Файлы:
 

В статье Вы пишите:

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

Как я понял, эта функция работает только с массивом типа int, а если у меня массив другого типа, к примеру ushort, то как быть?