Это сэкономит мне огромное количество времени.
Нет, не будет. Гиперпоточность полезна, когда вы выполняете различные виды задач, которые используют дополнительные ресурсы внутри ЦП. Например, один поток использует много плавающей запятой, а другой нет. Пока первый выполняет математику с плавающей точкой, остальная часть ЦП доступна для другого потока.
По понятным причинам, куча потоков компиляции требует одинаковых внутренних ресурсов ЦП. Все, чего вы добьетесь - это иметь вдвое больше потоков, борющихся за кеш процессора и ресурсы. Увеличение нагрузки на кеш сделает жизнь медленнее, а не быстрее.
Итак, вышеизложенное объясняет, почему вы не получите БОЛЬШУЮ выгоду от Hyperthreading и однородного кода. Общепринятое мнение о параллельном изготовлении состоит в том, чтобы установить число заданий на одно больше, чем число ядер, при условии, что процессы 1 / N, вероятно, выполняют дисковый ввод-вывод. Конечно, это для Unix make, где задание выполняет большую часть обработки make-файла в дополнение к фактической компиляции.
Если вы повернули ручку до 8 и не увидели каких-либо изменений (обратите внимание, что это может быть отрицательное изменение пропускной способности по причинам, описанным выше) в диспетчере задач, о котором сообщалось об использовании ЦП, это, вероятно, вызвано взаимозависимостью в вашем решении. определенные задачи компиляции для запуска последовательно. Если одна задача зависит от вывода другой (часто это происходит с предварительно скомпилированными заголовками), это ограничивает количество одновременных заданий - даже если у вас 16-ядерная система, вы все равно не получите большего параллелизма, чем позволяет структура проекта.