![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Спасибо.
Это было увлекательно.
Положите файл итоговый в общую папку
или пропишите в файле Evolution-test.mq5 - в самой шапке привязку файла (будет передаваться тестеру) по имени(менять или добавлять при смене инструмента и тайм фрейма) и принудительное использование локальной папки терминала.
Учтите, если файла не будет и запустите тест, то придется перезапустить терминал, так как в кэше где то он запоминает, что файла нет - и ничего не поможет, кроме перезапуска...
Офигеть... всё заработало...
Большущее Вам спасибо, Алексей!
Офигеть... всё заработало...
Большущее Вам спасибо, Алексей!
Пожалуйста, успехов!
Код полезный, в том плане, что его очень мало на OpenCL на этом ресурсе. Ну и тема специфичная - автор молодец так то.
вот пример тестера для OCL, это прогон по истории нейронки. модуль алгоритма оптимизиции, конечно же, внешний.
гдето выкладывал уже, кому то может быть полезным как база для понимания как это дело работает. в коде OCL нет синхронизации ниток, на CPU работает быстрее чем на GPU задействуя все ядра, хотя может быть у меня видяха слабая была в 2012 году. время пришло переделать всё под текущие реалии. тогда я помню история по символу тупо не влезала в GPU, а тот обьём что влезал всёравно работал быстрее на CPU.
полностью код не позволяет разместить движёк форума, приложу в прикрепе.
вот пример тестера для OCL, это прогон по истории нейронки. модуль алгоритма оптимизиции, конечно же, внешний.
гдето выкладывал уже, кому то может быть полезным как база для понимания как это дело работает. в коде OCL нет синхронизации ниток, на CPU работает быстрее чем на GPU задействуя все ядра, хотя может быть у меня видяха слабая была в 2012 году. время пришло переделать всё под текущие реалии. тогда я помню история по символу тупо не влезала в GPU, а тот обьём что влезал всёравно работал быстрее на CPU.
полностью код не позволяет разместить движёк форума, приложу в прикрепе.
Спасибо за пример кода.
Однако, я не понял, как тут вообще реализовано последовательное обучение... По коду, кажется, что обучение проходит целиком по массивам истории, а где распараллеливание?
И, что это за типы переменных?
Спасибо за пример кода.
Однако, я не понял, как тут вообще реализовано последовательное обучение... По коду, кажется, что обучение проходит целиком по массивам истории, а где распараллеливание?
И, что это за типы переменных?
Этот код - соответствует одному прогону по истории (история подаётся как параметр), если сравнить со штатным оптимизатором, то один прогон на агенте.
Типы переменных - массивы структур.
Распараллеливание: представленный код OCL для одной нитки, таких ниток запускается заданное в параметрах движка OCL количество. Обычно - целиком популяция.
Что бы узнать, на какой конкретно нитке исполняется код служит переменная
int thread = get_global_id(0);
где get_global_id (0) - системная функция OCL.Прогон по истории - самая дорогая операция, её и имеет смысл распараллеливать. Есть другая сторона медали - передача больших объёмов данных - узкое горлышко в операциях с устройствами OCL, на GPU выгоднее делать много расчетов, а не обмениваться большими объёмами данных с ОЗУ процессора. Поэтому такой код как я представил оптимальнее работает на CPU, да, ниток (логических ядер) у CPU меньше чем у GPU, но зато обмен большими данными с ОЗУ быстрее.
Было бы хорошо уметь один раз переслать историю в GPU перед началом расчетов и впредь только подкидывать в него набор переменных которые нужно оптимизировать. С этим я пока не разобрался, может кто то подскажет, а пока до сих пор отправляю историю на OCL целиком каждый раз.
Распараллеливание: представленный код OCL для одной нитки, таких ниток запускается заданное в параметрах движка OCL количество. Обычно - целиком популяция.
Так это генетика? Типа сразу посчитали разные варианты и выбрали лучший?
Типы переменных - массивы структур.
Т.е. это название структур по сути? Не знал, что так можно передавать в OpenCL. Думал, что минимум должно быть какое то описание там.
Было бы хорошо уметь один раз переслать историю в GPU перед началом расчетов и впредь только подкидывать в него набор переменных которые нужно оптимизировать. С этим я пока не разобрался, может кто то подскажет, а пока до сих пор отправляю историю на OCL целиком каждый раз.
Не совсем понятно, что не понятно :) Вы копируете массив с историей в буфер в начале скрипта или при инициализации советника, и дальше с ней работаете.
Потом уже в каком то цикле ниже по коду меняете параметры переменных массивов, трете временные буферы.
1. Так это генетика? Типа сразу посчитали разные варианты и выбрали лучший?
2. Т.е. это название структур по сути? Не знал, что так можно передавать в OpenCL. Думал, что минимум должно быть какое то описание там.
3. Не совсем понятно, что не понятно :) Вы копируете массив с историей в буфер в начале скрипта или при инициализации советника, и дальше с ней работаете.
4. Потом уже в каком то цикле ниже по коду меняете параметры переменных массивов, трете временные буферы.
1. Вовсе не обязательно генетика. Просто сформированная пачка заданий. Популяционные в этом плане удобнее. Но сгодится и любой другой, который не требует обязательно последовательного получения результатов для оптимизации, по крайней мере который позволяет сформировать пачку заданий.
2. Да, просто названия структур. Удивительно, но как то это сильное колдунство работает, но нужно обязательно указывать размер структуры (или массива структур), иначе колдунство не сработает.
3.4. Вот с этим пока не понимаю. Надеюсь скоро руки дойдут и можно будет прямо в этой ветке позаниматься практически полезными извращениями с OCL. Да прибудет с нами сила.
Типа сразу посчитали разные варианты и выбрали лучший?
не, не сразу. популяцию посчитали за эпоху.
к примеру, делаем размер популяции 512 (количество логических ядер/ниток), проводим 1000 эпох, получаем на выходе 512'000 прогонов. для сравнения - штатный оптимизатор МТ5 делает в среднем только 10'000 прогонов.