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

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

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

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

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

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

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

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

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

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

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

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

Aliaksandr Hryshyn
2740
Aliaksandr Hryshyn  
Edgar Akhmadeev:

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

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

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

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

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

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

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

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

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

Boris Egorov
466
Boris Egorov  
Edgar Akhmadeev:

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

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

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

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

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

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

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

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

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

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