Вопрос о скорости оптимизации.

Новый комментарий
 
Вот такую странную штуку наблюдал сегодня:

Загрузил на выходные оптимизашку. Поскольку процессор с Hyper Threading, загрузил их две. (Здесь есть такой момент, что одна оптимизашка занимает ровно 50% мощности моего процессора и что ты с ним не делай, больше не становится. А две оптимизашки занимают 100%. Если постоять рядом с секудомером, можно отметить, что при запуске оптимизации на двух терминалах, время выполнения первой запущенной увеличивается на 20% по сравнению с тем, как если бы она была в одиночестве, а не на 100%, как можно было бы предположить. А время выполнения второй задачи увеличивается на 40%. Жаль, конечно, что терминал не умеет сам смотреть, насколько он может сейчас загрузить машину, но что делать...)

Итак, запустил оптимизацию на двух терминалах. Поскольку уже месяц работаю в том же духе, примерно предполагал, что закончится первая где-то часов через 20, а вторая - через 60. Но на этот раз залочил компьютер (заблокировал). С утра в понедельник пришёл, разлочил. Хм... Обе задачи говорят, что прошло 58 часов. Первая - что ей осталось ещё столько же (количество вариантов соответствует). Вторая - что ей осталось 1600 (!) часов и вообще, посчитано 200 вариантов из 10000. Ну, думаю, что это за хронологические новости? Ладно, некогда, закрутился обычный понедельник. Дела, дела... Задачи оставил - посмотрим, что они мне через пару часов скажут.

Сказали! Первая закончилась! Вот вам результаты, я за 3 часа сделала работу 60-ти :). Второй осталось 180 часов.

По мне, так это очень круто: 1400 часов за утро.

Разница в том, что компьютер был заблокирован. Системщик кричит, что этого не может быть, потому что этого не может быть никогда. И блокируется только клавиатура с мышей :)

Вот и не знаю, что тут думать.
 
Время тестирования очень сильно зависит от входных параметров индикатора, эксперта. Например, если в индикаторе есть параметр, указывающий, сколько баров использовать для анализа, то понятно, что время расчета 10 баров будет примерно в 2 раза меньше чем 20. Тестер оставшееся время вычисляет как затраченное время, деленное на количество пройденных итераций, умноженное на количество оставшихся итерация. Вот и получается, если первая итерация была самая долгая, то тестер выдаст бешеные цифры, а потом они у него будут все меньше, меньше и меньше. Я, например, параметры оптимизации делаю так, чтобы первая итерация была самой долгой (она у меня идет почти 2-е суток), а следующие 39 итераций (всего 40) у меня проходят за 3-е суток.
 
lsv:
Время тестирования очень сильно зависит от входных параметров индикатора, эксперта. Например, если в индикаторе есть параметр, указывающий, сколько баров использовать для анализа, то понятно, что время расчета 10 баров будет примерно в 2 раза меньше чем 20. Тестер оставшееся время вычисляет как затраченное время, деленное на количество пройденных итераций, умноженное на количество оставшихся итерация. Вот и получается, если первая итерация была самая долгая, то тестер выдаст бешеные цифры, а потом они у него будут все меньше, меньше и меньше. Я, например, параметры оптимизации делаю так, чтобы первая итерация была самой долгой (она у меня идет почти 2-е суток), а следующие 39 итераций (всего 40) у меня проходят за 3-е суток.
Я знаю. Спасибо, но нет. Задача привычная. Перебор отличался от, к примеру, соседнего компьютера, диапазоном дат (я хочу получить результаты оптимизации отдельно по периодам). То есть, на одном (существенно более слабом) компьютере шёл перебор за полтора года (и закончился), а на другом - шёл перебор за следующие 8 месяцев, и происходил он так, как описано в инициирующем сообщении темы.
 
C таким ниразу не сталкивались.
Кстати, запуск второго терминала на процессоре с HT практически может дать мизерный прирост скорости. HT- это не второй процессор.
 
Renat:
А с таким ни разу не сталкивались.
Кстати, запуск второго терминала на процессоре с HT практически может дать мизерный прирост скорости. HT- это не второй процессор.
Вот, а имеет место. Я ещё попробую приоритет процесса поднять, потому что есть версия, что система сочла скрисейвер важнее оптимизации :)

Про HT - я знаю, что глупость. Но цифры взял не из головы, а замерив производительность секундомером.

И ещё: где прочитать о том, как определяется количество вариантов при оптимизации генетическим методом? Меня интересует:
  1. Как зависит объявленное количество вариантов от количества вариантов для полного перебора? То есть, мне терминал рисует 10800 вариантов как для миллиона, так и для триллиона.
  2. От чего зависит фактическое количество вариантов (которое может быть как меньше объявленного, так и больше) (см. скриншоты).
И, по-моему, небольшой глюк: посмотрите на "оставшееся время" после окончания тестирования.





Вотъ.
 
К сожалению, Вы сразу не указали в первом сообщении, что используете генетический алгоритм. При его работе показывается только приблизительное количество проходов и расчет обычно резко прерывается ближе к концу. К указанному времени надо относиться критически. При использовании генетики тестер не знает, когда он найдет конец улучшения популяции.

С расчетом времени при превышении расчетного количества проходов мы разберемся. Спасибо!
 
Renat:
К сожалению, Вы сразу не указали в первом сообщении, что используете генетический алгоритм. При его работе показывается только приблизительное количество проходов и расчет обычно резко прерывается ближе к концу. К указанному времени надо относиться критически. При использовании генетики тестер не знает, когда он найдет конец улучшения популяции.

С расчетом времени при превышении расчетного количества проходов мы разберемся. Спасибо!
Спасибо. Хотя мне по-прежнему интересно, как расчитывается заявленное число проходов при оптимизации генетическим алгоритмом.
Новый комментарий