Вопрос скорости выполнения зависит слишком от многих факторов. В первую очередь от процедуры, которую вы хотите исполнять в потоке. Можно запустить одновременно множество потоков, но они будут упираться в ограничения в других местах - например, есть ограничение на количество подключений по сети, к БД, к жёсткому диску, ну, и собственно, количество процессоров.
Для исследовательских задач алгоритм улучшения примерно такой — сначала реализуете алгоритм, выполняющий поставленную задачу самым простым для реализации способом. Смотрите на времена выполнения, в частности можно и нужно использовать различные профайлеры, счётчики ресурсов и тп. Если после этого времена не устраивают - смотрите где происходят наибольшие потери — эти места и нужно править в первую очередь.
Повторюсь — улучшать нужно не то, что кажется исходя из каких-то там теоретических соображений, а то что реально показывает профайлер или трассировка выполнения.
Распределение вычислений по потокам может дать выигрыш в случае многопроцессорных систем (а может и не дать). При этом надо учитывать, что:
1. Потоки нужно создавать. Если расчётная функция выполняется сопоставимо со временем создания потока — нет смысла создавать поток.
2. Потоками нужно управлять. Им нужно передавать исходные данные, а также получать результаты. Потоки могут конкурировать и блокировать друг друга за ресурсы приложения, очереди с исходными данными или за способность записать результат.
3. Потоки могут быть независимыми или реализован конвейер. Во втором случае нужно правильно и согласовано организовать передачу данных между потоками — иначе все преимущества конвейерных вычислений уйдут в инфраструктуру обмена.
Можно реализовать следующим способом:
Запускается настраиваемое число потоков, которые в цикле берут данные из очереди типа ConcurrentQueue, обрабатывают их и результат кладут в кучу ConcurrentBag.
Указанные коллекции — потокобезопасные, то есть возможна безопасная работа с ними одновременно из многих потоков.
В моей задаче, для 4-х ядер оптимальное среднее время выполнения задачи с очередью 20000 элементов достигалось на 3-5 потоках.