Новая версия платформы MetaTrader 5 build 5120: улучшения и исправления - страница 27
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Похоже, достаточно использовать msvcrt::memcpy для единократной записи и далее множества чтений. С указателями только нужно разобраться.
Если использовать виртуальный тестер, это не должно быть проблемой.
Речь шла про гипотетическую реализацию, которая быстрее выложенной RAMDrive-реализации.
К сожалению, memcpy не подходит, т.к. metatester64.exe и terminal64.exe - разные процессы.
Речь шла про гипотетическую реализацию, которая быстрее выложенной RAMDrive-реализации.
К сожалению, memcpy не подходит, т.к. metatester64.exe и terminal64.exe - разные процессы.
Похоже, это просто особенности RAMDrive и нюансы работы с файлами. Нужен другой механизм.
Он должен быть еще и совсем простым, т.к. только чтение. Предполагаю, что производительность при использовании только одного блока не будет падать.
Надо научиться записывать кусок памяти данными и передавать указатель на него агентам. И тогда все будет летать.
если всё в рамках одного компа, то память можно шарить между процессами (если несколько компов то можно например через MPI)
насколько понимаю у вас 1 писатель (вообще даже однократный) и много читателей. Один раз что-то записалось и дальше все только читают
через расшаренную память это быстрее чем RAM-диск.
если всё в рамках одного компа, то память можно шарить между процессами (если несколько компов то можно например через MPI)
насколько понимаю у вас 1 писатель (вообще даже однократный) и много читателей. Один раз что-то записалось и дальше все только читают
через расшаренную память это быстрее чем RAM-диск.
Это предложение MQ разработчикам не создавать каждому агенту свой блок памяти с тиковой и баровой историей, а использовать 1 копию и чтобы все агенты из нее читали. Так получится кратная числу агентов экономия памяти. При этом не будет сильного замедления чтения из этого 1-го блока памяти, по сравнению с чтением из копий истории выделенных каждому агенту.
В моем случае с 2 процессорами (18+18=36 физ ядер) и 2-мя каналами в памяти - получилось еще и ускорить тестирование в 4 раза, если использовать не 1 копию на всех, а 3 блока памяти на 36 агентов. Думаю это из за более оптимального использования 2-х каналов памяти и 2-х процесоров.
получилось еще и ускорить тестирование в 4 раза
Скорее всего, ускорение получается за счет медленного пробрасывания тиков в OnTick при стандартном (не мат. вычисления) использовании Тестера.
На выходных посмотрю, что можно сделать по теме.
Скорее всего, ускорение получается за счет медленного пробрасывания тиков в OnTick при стандартном (не мат. вычисления) использовании Тестера.
На выходных посмотрю, что можно сделать по теме.
А что еще смотреть? Предложение по улучшению тестера внесено и показано, что как минимум память будет экономиться. А это существенный плюс. У людей и 128 Гб не хватает. У меня 176Гб - тоже впритык по 5Гб на 36 агентов. Но вчера видел агента, который 15 Гб использовал намолотив 4 млн сделок.
я в режиме мат. вычислений тестировал. По реал тикам было в разы медленнее.
А что еще смотреть?
Логично это продемонстрировать в воспроизводимых числах, как самое простое.
Сложнее - попробовать кратно ускорить решение с одним блоком на много агентов.
Логично это продемонстрировать в числах, как самое простое.
Ну там OnTick будут генерироваться - логично, что мат. вычисления быстрее. Или я не понял вашу идею.
попробовать кратно ускорить решение с одним блоком на много агентов.
Если получится, буду делать оптимизацию только в мат. режиме. Сплошные плюсы - и скорость и экономия на памяти. Т.е. можно гораздо бОльшую историю тиков использовать.