Многопоточность

Сделай так: по-быстрому создай (скопируй) ещё 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# не знаю.

Ладно, суть не в этом.
Я ваще спрашивал про многопоточность.
Что лучше, идти в сторону создания потоков или же запускать несколько копий программы?
Я так и не понял.

Ну вроде пояснили. В случае одной копии программы и много потоков стратегий, затык будет на вводе данных с диска и распаковке. В случае множества копий, затыка не будет, ибо распаковка будет в разых потоках для каждой копии. Вроде так.

Судя по тому, сколько разных мнение, можно догадаться самостоятельно - универсального рецепта нет. Все индивидуально от используемым программ, библиотек, способов организации работы с данными.

Эмм если у вас есть автотестер, кот сам генерит диапазон варьируемых параметров, то второе неприемлемо. Да и вообще неудобно.
Создавать потоки так то несложно. Что же касается загрузки - то если у вас скажем метров 300 данных, то вполне логично их в память засосать.
А 7 жестких дисков, это по-моему изврат. Проще память дорастить и все в нее подкачивать. Или же подкачивать в нее большой кусок и синхронизировать выполнение потоков так, чтобы они ждали
пока все выполнят прогон на этом куске и только потом выполнять следующий.