Из того, что я читал до сих пор, TBB использует шаблон пул потоков (пул рабочих потоков) для внутреннего использования, и он предотвращает такие плохие издержки, создавая рабочие потоки только один раз (что стоит сотни микросекунд).
Да, TBB предварительно выделяет потоки.Он не создает физически и не присоединяется к рабочим потокам всякий раз, когда видит parallel_for.OpenMP и другие параллельные библиотеки выполняют предварительное выделение ресурсов.
Но все еще есть издержки для пробуждения потоков из пула и отправки логических задач потокам.Да, TBB использует структуры данных без блокировки для минимизации накладных расходов, но все же требует некоторого количества параллельных накладных расходов (т. Е. Последовательной части).Вот почему руководство TBB советует избегать очень коротких циклов.
В общем, у вас должно быть достаточно работы, чтобы получить параллельное ускорение.Я думаю, что даже 1 миллисекунда (= 1000 микросекунд) слишком мала.Исходя из моего опыта, чтобы увидеть значимое ускорение, мне нужно было увеличить время выполнения примерно на 100 миллисекунд.
Если параллельные издержки TBB parallel_for действительно вас беспокоят, возможно, стоит попробоватьпростое статическое планирование.У меня нет хороших знаний о реализации статического планирования TBB.Но вы можете легко примерить OpenMP: omp parallel for schedule(static).Я считаю, что эти накладные расходы были бы минимальной параллельной стоимостью.Однако, поскольку он использует статическое планирование, выгода от динамического планирования (особенно когда рабочие нагрузки неоднородны) будет потеряна.