![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
реалтайм ядро может как то помочь?
Ставьте заведомо больше ядер и не доводите ситуацию до 100% загрузок одиночных ядер.
В сказки не надо верить, процессоры и планировщик потоков не работают так, как вы представляете себе.
В последних сборках прием потока тиков не влияет даже теоретически. Практически SymbolInfoTick уже сейчас работает с кэшом, но отдельные граждане продолжают искать черную кошку.
А у него в тесте и не 80% даже. Там 6 агентов пашут на 4 ядрах, т.е. гарантировано 100%.
Вопрос только в том, как справляется с этой ситуаций планировщик задач его системы. При этом делаются утверждения, что виновата именно реализация терминала.
Т.е. искусственно создается ситуация, когда компьютер загружен сверх всякой меры, когда на нем тормозит буквально всё, а потом делаются заявления в стиле "ой, смотрите, а почему это вот там терминал иногда имеет лаги".
Закроем глаза, что даже в таких условиях это "примерно 0.01%" - к черту подробности! Достаточно заявить, что "средняя температура по больнице никого не волнует", "лаги создают проблемы во время торговли" и "хотим HFT".
Более того, конечно же, хотим чтобы HFT был в 20 экспертов на старом офисном десктопе или дохлой виртуалке.
PS PositionSelectByTicket() в своей реализации безусловно имеет доступ к разделяемому ресурсу с синхронизацией доступа. А если не селектить позицию на каждом вызове, то вы читаете старую цену. Проще было сделать "снепшот" через SymbolInfoDouble.
спасибо
вопрос мой возник, т.к. полгода назад оптимизировал код и тестировал скорость работы системных функций, полгода назад SymbolInfoDouble был медленнее SymbolInfoTick
а так в целом, наверное правду говорите, сегодня специально гуглил пару статей про кэш многоядерных процессоров (давно не интересовался этой инфой ),
вот краткая статья https://i2hard.ru/publications/25666/
суть, что на выполнение в АЛУ попадают данные исключительно из L1-кэша, который очень мал, и если загружать процессор на "всю катушку", то действительно - тест превратится в тест операционки + тест скорости работы процессорного кэша (загрузки, предсказания L1+L3 данных) , но никак не в тестирование производительности кода (приложения)
fxsaber , а если поставить низкий приоритет для агентов в диспетчере задач, а для MT5 высокий?
Не могу найти утилитку, которая бы блокировало выделение для всех программ/потоков ОС ресурса в виде конкретного потока ЦП, иначе можно было бы для MT5 резервировать поток и автоматически блокировать его занятие для других программ, что могло бы в теории снизить лаги.
В последних сборках прием потока тиков не влияет даже теоретически. Практически SymbolInfoTick уже сейчас работает с кэшом, но отдельные граждане продолжают искать черную кошку.
Отдельный гражданин достал из широких штанин дубликатом бесценного груза MQL-код, который показал, что в одних и тех же условиях костыль работает быстрее штатной функции.
Но Вы утверждаете, что Ваша функция хорошая, просто она имеет ограничения на условия использования.
А у него в тесте и не 80% даже. Там 6 агентов пашут на 4 ядрах, т.е. гарантировано 100%.
Вопрос только в том, как справляется с этой ситуаций планировщик задач его системы. При этом делаются утверждения, что виновата именно реализация терминала.
Т.е. искусственно создается ситуация, когда компьютер загружен сверх всякой меры, когда на нем тормозит буквально всё, а потом делаются заявления в стиле "ой, смотрите, а почему это вот там терминал иногда имеет лаги".
6/8 - ничего не тормозит. Браузеры, компиляция, отладка и т.д. параллельно пашут без каких-либо намеков на тормоза.
Но сейчас специально все отключил, оставив только 4/8 Агента. Ситуация не изменилась с тормозами Вашей функции.
Более того, конечно же, хотим чтобы HFT был в 20 экспертов на старом офисном десктопе или дохлой виртуалке.
Быстрая машина использовалась. И только 6 чартов уже давали тормоза.
PS PositionSelectByTicket() в своей реализации безусловно имеет доступ к разделяемому ресурсу с синхронизацией доступа. А если не селектить позицию на каждом вызове, то вы читаете старую цену. Проще было сделать "снепшот" через SymbolInfoDouble.
И такое использую.
О какой скорости в боевом исполнении может идти речь когда в терминале есть проблемы.
Эксперт сканрует все финансовые инструменты и ищет заданный паттерн.
Натыкается на финансовый инструмент и виснет наглухо!!!
Код из справки, я проставил только шаги, фин инструмент с проблемой и таймер:
Результат работы:
Конца выполнения скрипта я так и не дождался.
Пока в терминале есть такие баги, ни о каком боевом исполнении речи быть не может!!!
Ожидалось что когда финансовый инструмент попадает в обзор рынка то по нему как минимум подтягиваются все его свойства и дата начала истории. Если истории нет на сервере, то
SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date)
Должна вернуть NULL моментально, почему время выполнения 18446744073475877138 ?
Может я чего не знаю? Функции CopyXXX так же зависают на 16-29 секунд!!!
Это же не нормально, если у брокера 3000-6000 финасовых инструментов.
Может я чего не знаю? Функции CopyXXX так же зависают на 16-29 секунд!!!
Это же не нормально, если у брокера 3000-6000 финасовых инструментов.
Бары - зло. Поэтому просьба в другой ветке постить про них.
Бары - зло. Поэтому просьба в другой ветке постить про них.
Может быть Вы знаете как программно выбрать финансовый инструмент и не зависнуть на века ?
Может быть Вы знаете как программно выбрать финансовый инструмент и не зависнуть на века ?
Не сталкивался с такой задачей.
fxsaber , а если поставить низкий приоритет для агентов в диспетчере задач, а для MT5 высокий?
Не могу найти утилитку, которая бы блокировало выделение для всех программ/потоков ОС ресурса в виде конкретного потока ЦП, иначе можно было бы для MT5 резервировать поток и автоматически блокировать его занятие для других программ, что могло бы в теории снизить лаги.
Выставил для всех Агентов самый низкий приоритет.
Не помогает.
ЗЫ На результат влияет количество запущенных советников.
Уважаемые разработчики, могли бы Вы сообщить, как вычисляется MQL_MEMORY_USED?
Сделал расчет памяти, что занимают все переменные советника.
Это меньше 10%. Если правильно понимаю, то в MQL_MEMORY_USED входит History-кеш и CopyTicks-кеш. Но это все равно значительно меньше должно занимать.
При этом параллельный советник кушает в несколько раз меньше. Хотя принцип тот же.
В общем, что входит в это значение?
ЗЫ Сохранил шаблон с советником и к этому же чарту применил, вызвав перезагрузку. Стало так.
Потребление памяти изменилось почти на порядок. Сложно пока объяснить, что это обозначает.