Использую i7-2600k (4 ядра по 2 потока, 4400 МГц)/8ГБ RAM.
Оптимизирую API-скрипт ~300 тысяч прогонов.
Кэш - 4 ГБ, 8-10 потоков.

История - часовики за 2 года.
В 32-битной версии оптимизация занимает чуть более 3 часов при загрузке всех ядер процессора на уровне 90%.
В 64-битной версии - почти 7 часов при загрузке процессора около 50%.
Как я понимаю, это обусловлено двукратным увеличением объема информации в 64-битном представлении и производительность упирается в память.
До разгона процессора (штатная частота 3,4 ГГц) в 32-битном режиме его загрузка была под 100%.

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

круто, спасибо
я, наивный, думал от 64 битной версии получаю выигрыш

проблема больше в "сборщике мусора" в NET 3.5. Он однопоточный и притормаживает остальные потоки, когда работает. в NET 4.0 сборщик мусора работает параллельно оснвной программе.

когда переходите на net 4.0?

Установил TSLAB на вторую систему (Intel i5-4590, 4 ядра/4 потока/ 8GB RAM).
Неожиданно по сравнению со старой (Intel i7-2600k, 4 ядра / 8 потоков / 8GB RAM / разгон процессора до 4.4 ГГц) обнаружил значительное ускорение оптимизации, до 30-40% по времени (за ночь оптимизировалось то, что раньше только днем заканчивалось). И это при уменьшении потоков оптимизации с 9 до 5, в соответствии с рекомендациями в документации TSLAB.

После неоднократного повторения решил поэкспериментировать, в результате чего выяснил, что оптимальное количество потоков равно количеству ядер плюс/минус один, без учета hyperthreading. То есть уменьшение количества потоков до 4 для процессора i7-2600k ускоряет оптимизацию. Более того, даже однопоточная оптимизация медленнее максимум в полтора раза, чем 4-9 поточная.
И также, как и в 2012 году (первый пост), оптимизация в 32-битном режиме осуществляется быстрее, чем в 64-битном.

И опять тот же вывод - скорость оптимизации лимитируется в значительной степени подсистемой памяти (DDR3, 2-канальный режим).

т.е. оптимизацию сравнивал в чистом виде при использовании 1канального и 2х канального режимов?

Память только в 2-канальном режиме.

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

Можно и дальше проводить эксперименты, но пока нет времени на это. И было бы интересно проверить на 16-24 ядерной системе c XEON-ами или с 4-канальной DDR4.

С другой стороны, оптимизацию легко можно кратно ускорить изменением глубины истории котировок, шага и области параметров оптимизации и т.п.

вопрос возможно в том что за скрипт оптимизируется. Это сильно играет роль на ускорение от потоков.