Вопрос разработчикам - использование всех вычислительных ядер при оптимизации - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Это не верный подход - нужно не задания по одному давать, а перераспределять мощности, если есть свободные ресурсы, т.е. отменять уже выданные задания и отдавать их на исполнения другим. При этом нужно вести аналитику производительности каждого агента, что б отдать ядру на исполнение нужное число новых заданий.
это бред полный, уж извините
> отменять уже выданные задания и отдавать их на исполнения другим
думаю это вообще не реально, да и зачем, когда проще создать пакет заданий, отдать одно задание первому свободному потоку, дождаться пока оно выполниться, дать следующее задание первому освободившемуся потоку (обращаю внимание на слово поток, а не ядро процессора, ограничение на потоки надо убрать - это не право программистов, а право пользователя, напомню сейчас в качестве сетевых потоков выступают только реальные ядра, а не потоки, что искусственно занижает производительность в два раза)
>нужно вести аналитику производительности каждого агента, что б отдать ядру на исполнение нужное число новых заданий.
а это вообще не нужно, потому как ядра одного процессора с одинаковой производительностью в зависимости от заданий считают с разной скоростью, нафига что то там считать когда можно вообще ничего не считать
это бред полный, уж извините
> отменять уже выданные задания и отдавать их на исполнения другим
думаю это вообще не реально, да и зачем, когда проще создать пакет заданий, отдать одно задание первому свободному потоку, дождаться пока оно выполниться, дать следующее задание первому освободившемуся потоку (обращаю внимание на слово поток, а не ядро процессора, ограничение на потоки надо убрать - это не право программистов, а право пользователя, напомню сейчас в качестве сетевых потоков выступают только реальные ядра, а не потоки, что искусственно занижает производительность в два раза)
>нужно вести аналитику производительности каждого агента, что б отдать ядру на исполнение нужное число новых заданий.
а это вообще не нужно, потому как ядра одного процессора с одинаковой производительностью в зависимости от заданий считают с разной скоростью, нафига что то там считать когда можно вообще ничего не считать
Похоже у Вас скудный опыт работы с оптимизатором, и Вы не понимаете, что информация о завершенных проходах приходит с опозданием, что после выполнения задания агент отправляет фрейм, который может быть очень тяжелым, всё это приведет к задержкам на коммуникацию и замедлит оптимизацию. Поэтому, задания нужно выдавать пачками и следить за динамикой их выполнения - выдавая новые задания тем агентам, которые близки к завершению работ.
Похоже у Вас скудный опыт работы с оптимизатором, и Вы не понимаете, что информация о завершенных проходах приходит с опозданием, что после выполнения задания агент отправляет фрейм, который может быть очень тяжелым, всё это приведет к задержкам на коммуникацию и замедлит оптимизацию. Поэтому, задания нужно выдавать пачками и следить за динамикой их выполнения - выдавая новые задания тем агентам, которые близки к завершению работ.
>Похоже у Вас скудный опыт работы с оптимизатором,
пошутили??? 6 лет непрерывно
>информация о завершенных проходах приходит с опозданием, что после выполнения задания агент отправляет фрейм, который может быть очень тяжелым, всё это приведет к задержкам на коммуникацию и замедлит оптимизацию. Поэтому, задания нужно выдавать пачками и следить за динамикой их выполнения - выдавая новые задания тем агентам, которые близки к завершению работ.
>это приведет к задержкам на коммуникацию и замедлит оптимизацию.
а это не имеет значения, сети сейчас быстрые.
а вот то что ядра простаивают пока одно несчастное ядро досчитает кучу заданий из пачки крайне замедляет оптимизацию потому что все остальные (десятки ядер) стоят, ядра должны считать непрерывно и без остановок
похоже вы вообще никогда не оптимизировали по множеству параметров ... и не спорьте у вас нет практического опыта
>Похоже у Вас скудный опыт работы с оптимизатором,
пошутили??? 6 лет непрерывно
>информация о завершенных проходах приходит с опозданием, что после выполнения задания агент отправляет фрейм, который может быть очень тяжелым, всё это приведет к задержкам на коммуникацию и замедлит оптимизацию. Поэтому, задания нужно выдавать пачками и следить за динамикой их выполнения - выдавая новые задания тем агентам, которые близки к завершению работ.
>это приведет к задержкам на коммуникацию и замедлит оптимизацию.
а это не имеет значения, сети сейчас быстрые.
а вот то что ядра простаивают пока одно несчастное ядро досчитает кучу заданий из пачки крайне замедляет оптимизацию потому что все остальные (десятки ядер) стоят, ядра должны считать непрерывно и без остановок
похоже вы вообще никогда не оптимизировали по множеству параметров ... и не спорьте у вас нет практического опыта
Нельзя быть самоуверенным эгоистом, сети у него быстрые, как эгоцентрично. Напротив, сети не быстрые, если речь встает о десятках и сотнях мегабайтах.
Примитивная оптимизация советника - это не всё, для чего используется оптимизация - расширяйте свои горизонты и пользуйтесь математическим вычислением.
Да, и учитывайте, что это в первую очередь проект для прибыли, а не для радавания пользователей, и в связи с этим механизм должен учитывать рандомную раздачу заданий и верный финансовый учет их выполнения...
Нельзя быть самоуверенным эгоистом, сети у него быстрые, как эгоцентрично. Напротив, сети не быстрые, если речь встает о десятках и сотнях мегабайтах.
Примитивная оптимизация советника - это не всё, для чего используется оптимизация - расширяйте свои горизонты и пользуйтесь математическим вычислением.
Да, и учитывайте, что это в первую очередь проект для прибыли, а не для радавания пользователей, и в связи с этим механизм должен учитывать рандомную раздачу заданий и верный финансовый учет их выполнения...
десятки и сотни мегайбайт - это ничто, затраченное время минимально и кстати это тут вообще ни при чём, вы бы подумали прежде чем писать, что пакетом что по одному все равно этот трафик придется передать
>Примитивная оптимизация советника - это не всё, для чего используется оптимизация - расширяйте свои горизонты и пользуйтесь математическим вычислением.
вот про горизонты вам того же желаю
и про эгоизм тоже
и у меня далеко не примитивная, и вообще для чего он нужен тогда, ну просвятите нас неучей
вашу инициативу с точки зрения временных затрат и скорости оптимизации считаю полностью абсурдной
Вы просто рассматриваете свой частный случай оптимизации, а Алексей - свой (у него советник несколько сот Мб и долго пересылается).
А MQ смотрят на общее использование оптимизатора и подгоняют его под большинство, а не под вас с Алексеем.
Задачи перераспределяются, по крайней мере у меня на локальных ядрах. Если где-то не перераспределяются, дайте пример для воспроизведения, чтобы разработчики могли учесть и его.
Вы просто рассматриваете свой частный случай оптимизации, а Алексей - свой (у него советник несколько сот Мб и долго пересылается).
А MQ смотрят на общее использование оптимизатора и подгоняют его под большинство, а не под вас с Алексеем.
Задачи перераспределяются, по крайней мере у меня на локальных ядрах. Если где-то не перераспределяются, дайте пример для воспроизведения, чтобы разработчики могли учесть и его.
Согласен, что случай у меня частный.
Проблема есть с выделением заданий, если подключаются новые удаленные агенты - так бывает, когда ресурсы высвобождаются от других задач.
Вы просто рассматриваете свой частный случай оптимизации, а Алексей - свой (у него советник несколько сот Мб и долго пересылается).
А MQ смотрят на общее использование оптимизатора и подгоняют его под большинство, а не под вас с Алексеем.
Задачи перераспределяются, по крайней мере у меня на локальных ядрах. Если где-то не перераспределяются, дайте пример для воспроизведения, чтобы разработчики могли учесть и его.
наверно у меня тоже частный, но правда "наверное"
>дайте пример для воспроизведения, чтобы разработчики могли учесть и его.
не реально ... я свой советник выкладывать не могу, стандартные мне не интересны, могу сделать скриншоты чтобы было видно что не перераспределяются
если бы они перераспределялись - это было бы решение проблем
в три раза увеличенное время расчета .... доведут ли оптимизатор когда нибудь до нормальной работы???? куча свободных ядер простаивает ...
вторые сутки ничего не считает, все ядра в количестве 12 локальных и еще около 30 сетевых простаивают, специально не трогаю ... полный перебор, не знаю о чём там оно думает, наверно смысл жизни ищет или лекарство от короновируса :-)
думаю надо отказываться от оптимизатора ввиду его неработоспособности и тормознутости
и последние решения принятые МТ типа ограничить только физическими ядрами, упорно и тупо раздавать по куче заданий только определенным ядрам а не каждому ядру - одно задание - говорит о тотальном непонимании разработчиками высокопроизводительных расчетов