Влияние гиперпотока на производительность компилятора?

Скажем, мы хотим как можно быстрее скомпилировать большой проект (например, GCC или ядро Linux). Имеет ли процессор с возможностью hyperthreading (например, Intel Core i7) быстрее запускать компилятор с включенным или отключенным гиперпотоком? Есть ли опубликованные тесты, которые проверяют это?Влияние гиперпотока на производительность компилятора?

Мое понимание гиперпоточности заключается в том, что каждое ядро может выбирать команды из двух (или нескольких процессов). Это обычно делает ядро более эффективным, так как менее вероятно, что функциональные блоки будут бездействовать. Тем не менее, существует потенциал для снижения производительности, поскольку процессы, выполняющиеся на одних и тех же основных ресурсах, таких как кеш, и могут мешать друг другу. Независимо от того, действительно ли производительность повышается, зависит от рабочей нагрузки.

Итак, для рабочей нагрузки компилятора увеличивается производительность? Если да, то на сколько?

источник

2010-01-06 Jay Conrod

У меня нет недавнего опыта с этим, но компиляция не связана с I/O-bound? – Ken

Играйте с «make -j N» и измерьте системные ресурсы для разных N? –

@Nikolai, если бы у меня был процессор с гиперпотоком, с которым можно было играть. Я спрашиваю об этом, поэтому я знаю, стоит ли покупать. –

Сборка Coreutils-8.4 на Ubuntu 8.04 x86

Intel Atom 1,6 ГГц с HT включен:

~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make > /dev/null 

real 2m33.375s 
user 2m22.873s 
sys  0m10.541s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make -j2 > /dev/null 

real 1m54.707s 
user 3m26.121s 
sys  0m13.821s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make > /dev/null 

real 2m33.372s 
user 2m22.753s 
sys  0m10.657s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make -j2 > /dev/null 

real 1m54.851s 
user 3m26.145s 
sys  0m13.685s 
~/coreutils-8.4$

Так гиперпоточный сокращает время работы до 75%, что эквивалентно 33% больше вычислительная мощность. (Я побежал их дважды, чтобы убедиться, что все находится в кэш-памяти.)

А вот контрольный эксперимент, чтобы показать, что только make -j2 не улучшает скорость составления Coreutils-8.4 на Ubuntu 8.04 x86

Single -core Core 2 Quad 2,5 ГГц VM (нет HT):

~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make > /dev/null 

real 0m44.453s 
user 0m38.870s 
sys  0m5.500s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make -j2 > /dev/null 

real 0m45.131s 
user 0m40.450s 
sys  0m4.580s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make > /dev/null 

real 0m44.621s 
user 0m39.090s 
sys  0m5.340s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make -j2 > /dev/null 

real 0m45.165s 
user 0m40.390s 
sys  0m4.610s 
~/coreutils-8.4$

источник

2010-04-01 23:41:51 netvope

Это замечательно. Контрольный эксперимент показывает, что это действительно имеет значение. Спасибо. –

Мне бы хотелось увидеть повторные измерения на Atom с отключенным HT, предполагая, что это возможно. Кроме того, примечание об использовании памяти было бы неплохо, так как Atom мог начать замену или удаление кэшей, особенно в случае -j2. – Eroen

In-Order Atom хуже использует параллелизм на уровне инструкций, чем CPU Nehalem или Sandybridge, или AMD Ryzen. HT может помочь больше в Atom, чем в основном процессоре.Или это может помочь меньше, потому что основные процессоры имеют больше кешей и больше ресурсов исполнения (и более высокие отклонения от ветвления, а HT - другой поток, использующий CPU, в то время как один восстанавливается из неправильной спекуляции). Таким образом, вероятно, HT помогает значительно в основных процессорах, но соотношение может быть довольно различным. –

Все зависит от того, написан ли компилятор многопоточным или нет. Если это так, то определенная гиперпоточность ускоряет работу с тех пор, после чего ОС может планировать разные части потоков компилятора на разные ядра. Я согласен с Кеном в том, что компиляции, как правило, связаны с большей нагрузкой на ввод-вывод, чем интенсивность обработки, поэтому наличие скоростного жесткого диска будет более требовательным, чем быстрый процессор с 100 ядрами.

источник

2010-01-06 18:15:55 ajawad987

Как насчет того, вызван ли компилятор с make -j N (N - количество логических процессоров)? Я обеспокоен тем, что, поскольку отдельные процессы компилятора не делят каких-либо данных, они значительно снижают производительность. –

1) Компиляция (на Linux в любом случае) всегда может выполняться не-io-bound, при условии наличия достаточной физической памяти. 2) Популярные системы сборки могут ссылаться на многие процессы компилятора параллельно, делая многопотоковые компиляторы неэмиссионными. (тем не менее, для линкеров) – Eroen

Влияние гиперпотока на производительность компилятора?

ответ

Смежные вопросы