#15480 - Tue Oct 19 2010 09:44 AM
API оптимизации
|
member
Registered: Mon Jun 28 2010
Записи: 103
|
Есть ли планы по реализации открытого API для доступа к оптимизации. На хорошей железяке многопоточность затыкается, где-то есть bottleneck. Вот на таком сервере 8 миллионов проходов собирается идти 1400 часов (2 месяца). На скрине загрузка процессоров, это работа TSLab, более 30% ядра не загружаются.
Отредактировано Nab0y (Tue Oct 19 2010 09:47 AM)
|
|
Наверх
|
|
|
|
|
#15482 - Tue Oct 19 2010 10:26 AM
Re: API оптимизации
[Re: Nab0y]
|
Pooh-Bah
Registered: Mon Feb 16 2009
Записи: 2130
|
Есть ли планы по реализации открытого API для доступа к оптимизации. На хорошей железяке многопоточность затыкается, где-то есть bottleneck. Вот на таком сервере 8 миллионов проходов собирается идти 1400 часов (2 месяца). На скрине загрузка процессоров, это работа TSLab, более 30% ядра не загружаются. Рекомендации. 1. x64 2. Настроить TSLab на железку http://www.tslab.ru/docs/online/programoptions.htm--------------------------------------------------------- Расширенные практические советы по настройке режимов оптимизации: Кол-во потоков оптимизации выбираем равным числу ядер процессора + 1 или +2. Для процессоров ай7 и других гиперсрединговых Кол-во потоков оптимизации выбираем равным числу ядер умножить на два плюс 1, либо 2, либо 3. Кеш для скриптов для х86 - 640 Мб, если в системе 2 гигабайта оперативной памяти Кеш для скриптов для х86 - 256 Мб, если в системе меньше двух гигабайта оперативной памяти (1 гигабайт) Кеш для скриптов для х64 - 2 гигабайта, если в системе 4 гигабайта оперативной памяти Кеш для скриптов для х64 – половину от имеющейся, если в системе больше 4 гигабайт оперативной памяти --------------------------------------------------------- 3. Параметры оптимизации разбить на смысловые группы. Оптимизацию вести по группно.
|
|
Наверх
|
|
|
|
|
#15487 - Tue Oct 19 2010 11:21 AM
Re: API оптимизации
[Re: andy]
|
member
Registered: Mon Jun 28 2010
Записи: 103
|
1. На сервере WinServer2003 x64, соответственно и TSLab x64. 2. На сервере 32 ядра, согласно вашему-же коду public Optimization(IOptimizationCallback callback, int threads, IDictionary<string, OptPropertyParam> optParams, long iterations, long optCounter, long optStep)
{
this.m_callback = callback;
this.m_optParams = optParams;
this.m_optCounter = optCounter;
this.m_optStep = optStep;
this.m_realCounter = this.m_iterations = iterations;
[b]if (threads <= 0)
{
int processorCount = Environment.ProcessorCount;
s_log.Info(string.Format("Found {0} processors.", processorCount));
threads = processorCount + 1;
}[/b]
this.m_semaphore = new Semaphore(threads, threads);
}
Что я поставлю 33, что 0 результат будет одинаковый, программа сама способна определять сколько у меня ядер. В настройках программы под скрипты выделено 10 Гб из существующих 64, я проверял, что 5Гб, что 10Гб погоды сильно не делают. 3. До этого все время разделял оптимизацию на группы, но столкнулся с такой ситуацией, когда в процессе оптимизации первой группы и статически заданными параметрами второй группы, результаты оптимизации (именно значения параметров первой группы) сильно отличаются, если начать оптимизацию первой группы с другими параметрами второй. Запутано, но если коротко, они сильно взаимосвязаны, поэтому решил прогнать один раз все, чтобы хоть примерно знать оптимальные параметры. 4. Если будет хоть пример, как запустить хоть один проход оптимизации скажем в другом консольном приложении, я уже сам докурю, как написать распределенную оптимизацию на куче клиентских машин и сливом результатов, скажем в базу для последующей работы с ними.
|
|
Наверх
|
|
|
|
|
#15552 - Wed Oct 20 2010 11:43 AM
Re: API оптимизации
[Re: Robotorgovetc]
|
Carpal Tunnel
Registered: Thu Oct 23 2008
Записи: 5492
|
Все дело в том, что распределитель задач - однопоточный. Если сама история короткая и считается один проход очень быстро (меньше 50мс), то программа просто не успевает загрузить столько ядер на 100%. Большое количество ядер получается загрузить, когда история очень длинная и расчет идет довольно долго (чем дольше, тем лучше загрузка). То же самое касается памяти. Если история короткая, то все варианты индикаторов занимают ограниченный объем памяти и много ее просто не нужно.
Нужно помнить, что есть еще синхронизация, связанная с тем, что если какой-то индикатор с определенными значениями уже считается в каком то из потоков, то другие потоки, которые запросили такой же индикатор, просто ждут расчета.
В общем, пробуйте просто наращивать количество потоков, участвующих в расчетах, но в любом случае, с короткой историей загрузки близкой к 100% достичь не получится.
|
|
Наверх
|
|
|
|
|
#15556 - Wed Oct 20 2010 11:57 AM
Re: API оптимизации
[Re: Nab0y]
|
Pooh-Bah
Registered: Sun Feb 21 2010
Записи: 2331
Loc: Ухта
|
3. До этого все время разделял оптимизацию на группы, но столкнулся с такой ситуацией, когда в процессе оптимизации первой группы и статически заданными параметрами второй группы, результаты оптимизации (именно значения параметров первой группы) сильно отличаются, если начать оптимизацию первой группы с другими параметрами второй. Запутано, но если коротко, они сильно взаимосвязаны, поэтому решил прогнать один раз все, чтобы хоть примерно знать оптимальные параметры.
. То что Вы прогнав "всё" без разбивки на смысловые группы получите оптимальные параметры на мой взгляд в корне не верно. Оптимизация в ТСлаб, насколько я понимаю, осуществляется простым перебором ВСЕХ сочетаний параметров, заложенных в оптимизацию, поэтому вы обязательно выловите всевозможные нетипичные "выбросы" в графике цены, которые дадут вам весомую дутую прибавку в доходности на истории, не имеющую реального основания. Я полагаю разбивка на группы дает - ну скажем осторожнее- должна давать более оптимальные результаты..
|
|
Наверх
|
|
|
|
|
#15561 - Wed Oct 20 2010 12:42 PM
Re: API оптимизации
[Re: usas]
|
Pooh-Bah
Registered: Mon Feb 16 2009
Записи: 2130
|
Я полагаю разбивка на группы дает - ну скажем осторожнее- должна давать более оптимальные результаты.. Согласен. Пошаговая оптимизация параметров по группам дает качество поведения скрипта в риале. Тупой перебор в лоб, без проработки глазом трейдера, дает как правило отрицательное качество поведения скрипта в риале.
|
|
Наверх
|
|
|
|
|
|
Предыдущий топик
К началу
