Подтвердить что ты не робот

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

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

Ответ 2

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

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

Есть много вещей, которые влияют на время сборки, включая отношение ЦП к "привязке" ввода-вывода. По моему опыту (GCC в Linux) они включают в себя:

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

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

  • Отключено спящий режим: "powercfg -h off" в командной строке

  • Отключено индексирование диска на диске C

  • Файл с файлами обрезков до 800 мин /1024 макс (изначально был установлен размер управляемой системы 8092).