Ускорьте время компиляции с SSD

Question

Ускорьте время компиляции с SSD

Я хочу попытаться ускорить время компиляции наших проектов на C ++. У них есть около 3 миллионов строк кода.

Конечно, мне не нужно всегда компилировать каждый проект, но иногда есть много исходных файлов, измененных другими, и мне нужно перекомпилировать все из них (например, когда кто-то обновляет ASN.1 исходный файл).

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

Я попытался переместить исходный код на твердотельный накопитель (старый OCZ Vertex 3 60 ГБ), который, по оценкам, в 5–60 раз быстрее жесткого диска (особенно при случайном чтении / записи). В любом случае, время компиляции почти одинаково (возможно, на 2-3 секунды быстрее, но это должно быть шансом).

Может быть, перемещение бина Visual Studio в SSD даст дополнительный прирост производительности?

Просто для завершения вопроса: у меня W3520 Xeon с частотой 2,67 ГГц и 12 ГБ DDR3 ECC.

20

c++compilation ssd visual-studio-2010

Решение

Другие решения

Все это в значительной степени зависит от вашей среды сборки и других настроек. Например, на моем главном сервере компиляции у меня 96 ГБ ОЗУ и 16 ядер. Жесткий диск довольно медленный, но это не имеет значения, поскольку все кешируется в оперативной памяти.

На моем рабочем столе (где я также иногда компилирую) у меня только 8 ГБ ОЗУ и шесть ядер. Выполнение той же параллельной сборки может быть значительно ускорено, потому что шесть параллельно работающих компиляторов потребляют достаточно памяти, чтобы разница в скорости SSD была очень заметной.

Есть много вещей, которые влияют на время сборки, в том числе отношение «процессора» к «ограниченности» ввода / вывода. По моему опыту (НКУ в Linux) они включают в себя:

Сложность кода. Множество метатемплат заставляют его использовать больше процессорного времени, больше C-подобного кода может сделать ввод-вывод сгенерированных объектов (более) доминирующим
Настройки компилятора для временных файлов, например -pipe для GCC.
Оптимизация используется. Обычно, чем больше оптимизация, тем больше работа процессора.
Параллельные сборки. Компиляция одного файла за раз, вероятно, никогда не приведет к достаточному количеству операций ввода-вывода, чтобы получить самый медленный жесткий диск на сегодняшний день до любого предела. Компиляция с восемью ядрами (или более) одновременно, однако, может.
ОС / файловая система используется. Кажется, что некоторые файловые системы в прошлом подавляли схему доступа для многих файлов, построенных параллельно, по сути ставя узкое место ввода-вывода в код файловой системы, а не на базовое оборудование.
Доступная оперативная память для буферизации. Чем агрессивнее операционная система может буферизовать ваш ввод / вывод, тем менее важной становится скорость жесткого диска. Вот почему иногда make -j6 может быть медленнее, чем make -j4 несмотря на наличие достаточно холостых ядер.

Короче говоря: это зависит от того, достаточно ли вещей, чтобы сделать «да, это поможет вам» или «нет, это поможет вам», а не чистые спекуляции, поэтому, если у вас есть возможность опробовать это, сделайте это. Но не тратьте на это слишком много времени, поскольку каждый час вы пытаетесь сократить время компиляции пополам, пытайтесь оценить, как часто вы (или ваши коллеги, если они у вас есть) могли перестраивать проект, и как это связано с возможное время сэкономлено.

26

Я обнаружил, что компиляция проекта из примерно 1 миллиона строк C ++ ускорилась примерно в два раза, когда код находился на SSD (система с восьмиядерным процессором). Core i7, 12 ГБ ОЗУ). На самом деле, наилучшая возможная производительность, которую мы получили, была с одним SSD для системы и вторым для источника — не то, чтобы сборка была намного быстрее, но ОС была намного более отзывчивой, пока шла большая сборка.

Другая вещь, которая имела огромное значение, была возможность параллельного строительства. Обратите внимание, что есть две отдельные опции, которые нужно включить обе:

Меню инструменты → Опции → Проекты и Решения → максимальное количество параллельных сборок проекта
Свойства проекта → C ++ / Общие → Многопроцессорная компиляция

Многопроцессорная компиляция несовместима с парой других флагов (включая минимальное перестроение, я думаю), поэтому проверьте окно вывода на наличие предупреждений. Я обнаружил, что при установленном флаге компиляции MP все ядра нагружаются почти до 100% нагрузки, так что вы можете по крайней мере увидеть агрессивную загрузку процессора.

4

Один момент не упоминается, что при использовании CCache и высокопараллельная сборка, вы увидите преимущества использования SSD.

0

Я заменил свой жесткий диск на SSD, надеясь, что это сократит время компиляции моего C ++ проекта. Простая замена жесткого диска на SSD не решила проблему, и время компиляции с обоими было почти одинаковым.

Однако после первоначальных сбоев я добился успеха в ускорении компиляции примерно в шесть раз.

Следующие шаги были сделаны для увеличения скорости компиляции.

Выключил спящий режим: «powercfg -h off» в командной строке
Выключил индексацию диска на диске C
Сокращенный файл подкачки до 800 мин. / 1024 макс. (Изначально он был настроен на управляемый системой размер 8092).

-2

Источник

Accepted Answer

Компиляция / компоновка C ++ ограничена скоростью обработки, а не вводом-выводом жесткого диска. Вот почему вы не видите никакого увеличения скорости компиляции.
(Перемещение двоичных файлов компилятора / компоновщика на SSD ничего не даст. Когда вы компилируете большой проект, компилятор / компоновщик и необходимая библиотека считываются в память один раз и остаются там.)

Я видел некоторые незначительные ускорения при перемещении рабочего каталога на SSD или ramdisk при компиляции проектов C (что намного меньше времени, чем проекты C ++, которые интенсивно используют шаблоны и т. Д.), Но этого недостаточно, чтобы оно того стоило.

8