Вопрос разработчикам - использование всех вычислительных ядер при оптимизации - страница 8

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Aliaksandr Hryshyn
2909
Aliaksandr Hryshyn  
Интересный подход.
Мне тоже надо будет делать свой "велосипед".
Задача примерно такая:
количество параметров переменное;
в зависимости от значений могут появляться новые параметры или исчезать имеющиеся;
их количество может быть большое(30, 100, 200, бесконечность), думаю, что в среднем будет 20-50;
стратегия считается завершённой только при некотором сочетании значений имеющихся параметров, только у завершённой стратегии можно посчитать прибыль, просадку и т.д.;
мы легко(с вычислительной точки зрения) можем добавлять и убирать параметры, определять, какие параметры появляются и исчезают при изменении значений.

Надо придумать, как использовать тестер для получения хороших параметров. Параметры являются функциональными элементами стратегии. Есть возможность программно управлять тестером(запуск, остановка, изменение инструмента, дат, плечо, получение оценки времени расчёта, изменение параметров советника/индикатора и т.д.), получение результатов оптимизации (чтение кэша).
Есть какие идеи :) ? Пока ещё не дошёл до этого этапа разработки.
Andrey Dik
14067
Andrey Dik  
Aliaksandr Hryshyn:
Интересный подход.
Мне тоже надо будет делать свой "велосипед".
Задача примерно такая:
количество параметров переменное;
в зависимости от значений могут появляться новые параметры или исчезать имеющиеся;
их количество может быть большое(30, 100, 200, бесконечность), думаю, что в среднем будет 20-50;
стратегия считается завершённой только при некотором сочетании значений имеющихся параметров, только у завершённой стратегии можно посчитать прибыль, просадку и т.д.;
мы легко(с вычислительной точки зрения) можем добавлять и убирать параметры, определять, какие параметры появляются и исчезают при изменении значений.

Надо придумать, как использовать тестер для получения хороших параметров. Параметры являются функциональными элементами стратегии. Есть возможность программно управлять тестером(запуск, остановка, изменение инструмента, дат, плечо, получение оценки времени расчёта, изменение параметров советника/индикатора и т.д.), получение результатов оптимизации (чтение кэша).
Есть какие идеи :) ? Пока ещё не дошёл до этого этапа разработки.

может быть несколько решений этой задачи в зависимости от специфики.

если у всех параметров, тех которые уже есть и тех которые могут появится, будет строго определённое место в наборе параметров (хромосома или иной другой эквивалент), тогда вообще проблем нет.

если определённое место каждого параметра не может быть определено заранее, то нужно разделить параметры на типы, которые можно комбинировать строго только друг с другом (тогда не имеет значения на каком месте находится параметр) - потребуется модификация АО.

есть ещё другие варианты решения задачи, но потребуется в любом случае кастомный АО, надстройка над штатным.

Edgar Akhmadeev
2733
Edgar Akhmadeev  
Boris Egorov:
подтвердилась инфа о перегрузке памяти .... хотя странно, swap никто не отменял, опять же думаю разработчикам надо это учесть

Вы отписывайтесь, как решили проблему-то. Мы же за Вас волнуемся.

Сколько минимально памяти нужно на одного агента (уменьшали количество активированных, пока все не стали нагружаться равномерно?)

Увеличили pagefile? При этом физическая память будет постоянно свопиться, возможно сильное замедление, надо найти такое количество ядер, когда общее время оптимизации минимально.

Aliaksandr Hryshyn
2909
Aliaksandr Hryshyn  
Edgar Akhmadeev:

Вы отписывайтесь, как решили проблему-то. Мы же за Вас волнуемся.

Сколько минимально памяти нужно на одного агента (уменьшали количество активированных, пока все не стали нагружаться равномерно?)

Увеличили pagefile? При этом физическая память будет постоянно свопиться, возможно сильное замедление, надо найти такое количество ядер, когда общее время оптимизации минимально.

Это всё зависит от использования тиков, глубины истории, количества инструментов. Просто смотрите в диспетчер задач, там всё видно, объём всей оперативки минус 1-2 Гб для операционки деленное на используемый объём одним агентом. У каждого всё индивидуально.

Реально улучшить ситуацию могут разработчики, если для котировок и, возможно, для индикаторов будет использоваться одна область оперативной памяти.
Edgar Akhmadeev
2733
Edgar Akhmadeev  
Aliaksandr Hryshyn:

Это всё зависит от использования тиков, глубины истории, количества инструментов. Просто смотрите в диспетчер задач, там всё видно, объём всей оперативки минус 1-2 Гб для операционки деленное на используемый объём одним агентом. У каждого всё индивидуально.

Реально улучшить ситуацию могут разработчики, если для котировок и, возможно, для индикаторов будет использоваться одна область оперативной памяти.

Мне объясняете? Я объяснял человеку эту проблему, а теперь интересуюсь результатом. Обратной связи нет. 

А неэффективное использование памяти терминалом мы уже много раз обсуждали, да и MQ несколько раз обещала изменить ситуацию с дублированием истории тиков и временных файлов для каждого агента, и их длительным созданием перед каждой тиковой оптимизацией. Лично мне приходится отключать почти половину агентов и тиковой оптимизации за несколько лет. У меня 8Гб и 8 агентов. Но пока пользуемся тем, что есть, а мы можем либо увеличивать размер памяти, либо отключать агентов.

Boris Egorov
477
Boris Egorov  
Edgar Akhmadeev:

Мне объясняете? Я объяснял человеку эту проблему, а теперь интересуюсь результатом. Обратной связи нет. 

А неэффективное использование памяти терминалом мы уже много раз обсуждали, да и MQ несколько раз обещала изменить ситуацию с дублированием истории тиков и временных файлов для каждого агента, и их длительным созданием перед каждой тиковой оптимизацией. Лично мне приходится отключать почти половину агентов и тиковой оптимизации за несколько лет. У меня 8Гб и 8 агентов. Но пока пользуемся тем, что есть, а мы можем либо увеличивать размер памяти, либо отключать агентов.

>Вы отписывайтесь, как решили проблему-то. Мы же за Вас волнуемся.

>Я объяснял человеку эту проблему, а теперь интересуюсь результатом. Обратной связи нет.

Прошу прощения, работал, было некогда. 

Провел оптимизацию советника. Убрал некоторые "неважные" части ради того чтобы оптимизатор начал работать (а конкретно все что связано с OpenCL и SQLite). Теперь у меня нет переполнения памяти. НО ... это не решение конечно.

На другом пк чтобы не уходил в зависание просто пришлось отключить часть ядер ... так например система на 3950Х (16 ядер/32 потока) и 32 Гб - при использовании всех потоков - просто висла и все. Причом висли именно агенты и висело до тех пор пока руками не прибъешь процесс через таскменеджер .... Отключил часть ядер, пошел просчет. Думаю разработчики должны что то сделать чтобы проблема была явной. Если уж оптимизатору нужно именно надцать гигов памяти на просчет - это надо явно написать чем то типа алерта. Хотя еще раз напомню про своп. У меня установлен Xmeters ... так что загрузку памяти я вижу визуально прямо на панели задач.

Думаю есть еще какой то глюк связанный именно с CPU АМД и раньше такого не было - хотя советник был тот же. Симптомы такие - задействовано всего 5 ядер .... и просчет висит... и это точно не память, так как тот же советник считал при загрузке 16 потоками без проблем, и эта проблема какая то плавающая, то она есть то ее нет. Если запустить тест не в оптимизаторе - он нормально исполняется. Не раз замечал такое. Вообщем надо разбираться.

По поводу тормозов на сетевых агентах - воз и ныне там. "Одно ядро - одно задание" - недоступно для понимания разработчиков. Как и раньше 10 ядрам раздаст по 30 заданий, и еще 30 сетевых агентов простаивают. Долго раздает задания о чом то думая. Вообщем тут тормоза сплошные.

и да забыл: Всем огромное спасибо за участие, посильную помощь и советы.
Boris Egorov
477
Boris Egorov  

to Renat Fatkhullin

Все таки я хочу тему еще раз поднять и задать вопрос конкретно Renat Fatkhullin

1. Я выполняю оптимизацию на локальной ферме из нескольких совершенно разных по производительности серверах и увидел ну просто страшные задержки при оптимизации вызванные именно тем что CPU имеют разную производительность. Предположим есть сервера с CPU Xeon E5-2620 v2 (2.1 Ггц), Xeon E5-2620 0 (2,00 Ггц), i7-3820 (3.6 Ггц), Xeon E3-1245 (3,7 Ггц), Ryzen 7 2700 , Ryzen 9 3900X, Ryzen 9 3950X. Текущий алгоритм работает так: формирует пачку заданий, делит эту пачку заданий поровну на каждое доступное ядро. Теперь учитывая то что имеем тихоходные CPU Xeon E5-2620 0 (2,00 Ггц) и Xeon E5-2620 v2 (2.1 Ггц) получается что ферма посчитала свои задания и простаивает, а эти два CPU не просчитали и половины заданий. Таким образом вся ферма тупо стоит. Так происходит и будет происходить потому что CPU имеют разную скорость и до тех пор пока задания раздаются пакетами. Опыт показывает что сетевые задержки вообще не имеют значения и они ничтожны. Можно ли уже переделать алгоритм раздачи заданий: раздавать не несколько заданий каждому доступному ядру а "давать каждому освободившемуся ядру - одно задание из текущей пачки генерации"? 

2. Можно ли добавить сохранение результатов тестирования в xml файл каждые 10 минут ....и запуск с места последнего сохранения?

Renat Fatkhullin - MetaQuotes
  • www.mql5.com
Профиль трейдера
MetaQuotes
Админ
27944
Renat Fatkhullin  

Мы занялись полным переписыванием тестера и оптимизатора.

Будем кардинально переделывать и исправлять накопленные проблемы.

Aleksey Vyazmikin
16149
Aleksey Vyazmikin  
Renat Fatkhullin:

Мы занялись полным переписыванием тестера и оптимизатора.

Будем кардинально переделывать и исправлять накопленные проблемы.

Будет ли:

1. Более быстрая реакция на отвал агента, когда допустим, при отсутствии отзыва от агента выдача пакетов прерывается на минуты и пакеты перераспределяются.

2. Будит ли реализована возможность закачки в одном экземпляре данных для всех агентов на удаленной машине?

3. Будет ли решена проблема передачи больших объемов данных, когда с агентом рвется соединение недокачав все нужные для оптимизации данные (файлы)?

Boris Egorov
477
Boris Egorov  

Меня вот еще один момент беспокоит ....

допустим идет оптимизация и в этот момент происходит обновление метатрейдера агента .... при этом агент ведь имел задание (точнее пакет заданий), оно будет потеряно или будет пересчитано?

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий