English
Русский
Español
Deutsch
Português
日本語
Ребят, обьясните пожалуйста. Вот я написал код на тестирование пересечения скользящих средних и всякой другой хрени. При тестировании процессор загружается всего на 13%. Если я создам 7 потоков, то я сделаю тестов в 7 раз больше?
面向 .NET 和 Python 的算法交易✦
86+ 连接器 · 交易所 · 经纪商 · 加密货币✦
S#.Designer · 回测 · 优化 · 实盘✦
31,455+ 名交易者和开发者的社区✦
面向 .NET 和 Python 的算法交易✦
86+ 连接器 · 交易所 · 经纪商 · 加密货币✦
S#.Designer · 回测 · 优化 · 实盘✦
31,455+ 名交易者和开发者的社区✦
评论 (10)
登录 或 创建账户, 登录或注册以发表评论
Сделай так: по-быстрому создай (скопируй) ещё 6 копий стратегий, запусти их с разными параметрами вместе с базовой и сам увидишь, что из этого получится. Это быстрее и полезнее для тебя, чем ждать, что кто-то когда-то откликнется на твой вопрос.
В тестере 2 потока 1й грузит с диска и распаковывает тики и стаканы и помещает их в очередь 2й читает эту очередь и скармливает данные стратегиям, получает заявки от стратегий и эмулирует их
Если написать стратегию которая ничего не делает (и не тратит времени), то 2й поток будет в основном просто ждать когда 1й загрузит данные. Если добавить 7 копий этой быстрой стратегии, то все равно все будет упираться в скорость загрузки данных.
То что у вас загрузка 13% видимо означает что у вас много ядер. Сколько, кстати?
Поток загрузки данных полностью занимает одно ядро, а остальные простаивают.
К сожалению разумной схемы как использовать больше чем 1 ядро для загрузки и распаковки данных мы пока не придумали. Возможно в будущем это изменится.
У меня 4 реальных и 4 виртульных, пенек 2600. Чтоб скорость доступа к данным не тормозила программу у меня каждая копия считывает данные с отдельного винта, пришлось 7 жестких дисков воткнуть. Я всегда тестирую не один контракт, а склееный фьюч за 6,5 лет. А это очень долго, бывает 1 тест занимает несколько дней, но зато прогоняет десятки тысяч всевозможных вариантов. Мое мнение, тест истории 1 контракта из 27 существующих не совсем правильно. Надо смотреть как стратегия вела себя в разные времена.
Если уж бутылочным горлышком является ввод-вывод, почему бы не попробовать посмотреть в сторону SSD? 7 винтов - жесть...
Как писали умные люди, потратившие много времени на исследования, ввод вывод редко является проблемой. Почти всегда алгоритм расчета пожирает все процессорное время и является узким местом. Считать 300 мегабайт данных по фучу ртс за 3 года дело пары секунд. А вот обработать - уже часы. Поэтому не знаю зачем нужны 7 винтов итд.
Ну собственно тут выше сказано что распаковка данных и подготовка к работе пожирает все время одного ядра. А дальше еще стратегия будет, тоже сожрет :).
Я на самом деле еще на S# не перешел, не понимаю ещ как некоторые вещи в нем реализовать. И все ещ считываю данные с txt файлов, а вся тиковая история за 6,5 лет занимает порядка 8 Гб и поэтому приходится считывать их с разных дисков. Просто когда за раз 10000 вариантов прогоняешь, надо все эти результаты вести. Сейчас я знаю как это сделать, а в S# не знаю.
Ладно, суть не в этом. Я ваще спрашивал про многопоточность. Что лучше, идти в сторону создания потоков или же запускать несколько копий программы? Я так и не понял.
Ну вроде пояснили. В случае одной копии программы и много потоков стратегий, затык будет на вводе данных с диска и распаковке. В случае множества копий, затыка не будет, ибо распаковка будет в разых потоках для каждой копии. Вроде так.
Судя по тому, сколько разных мнение, можно догадаться самостоятельно - универсального рецепта нет. Все индивидуально от используемым программ, библиотек, способов организации работы с данными.