Выбор ПК для компиляции больших кодовых баз
Компиляция — одна из более измеримых, чувствительных к железу задач разработчика — вот что реально двигает цифру.
Ранжировано по реальному влиянию
Для большинства современных, хорошо распараллеленных систем сборки количество ядер обычно имеет наибольшее влияние на время компиляции, за которым следует ОЗУ (избегание свопа) и скорость хранилища (обработка множества промежуточных файлов). Чистая тактовая частота одного ядра важна, но обычно меньше, чем эти три фактора, для больших многофайловых сборок.
- Количество ядер, для тулчейнов, которые параллелизуют компиляцию по файлам (большинство современных так и делают, часто по умолчанию). Больше ядер напрямую сокращает время настенных часов компиляции для больших проектов с множеством независимо компилируемых файлов.
- Объём ОЗУ, чтобы избежать отката системы к медленному свопу на основе диска в середине сборки — см. наше руководство по ОЗУ о том, почему этот откат так дорог. Большие проекты с множеством параллельных задач компиляции могут использовать больше ОЗУ, чем ожидается.
- Скорость хранилища, поскольку большая сборка читает и записывает множество промежуточных файлов — см. наше сравнение NVMe и SATA о том, насколько это реально важно по сравнению с разницей в спецификациях, которую вы бы не почувствовали в другом месте.
- Тактовая частота одного ядра, которая важна для частей сборки, которые нельзя распараллелить (некоторые этапы линковки, некоторые однопоточные этапы тулчейна) — реальный фактор, но обычно меньший, чем вышеперечисленное, для типичных больших многофайловых проектов.
Практическая форма рекомендации по сборке
| Приоритет | Обоснование |
|---|---|
| Процессор с большим количеством ядер | Напрямую сокращает время параллельной сборки |
| Достаточно ОЗУ, чтобы избежать свопа при пиковом использовании вашей реальной сборки | Избегание медленного отката к свопу важнее, чем люди ожидают |
| Быстрое NVMe-хранилище | Сокращает время на ввод-вывод промежуточных файлов |
| Приличная скорость одного ядра | Помогает нераспараллеливаемым частям, но вторичный приоритет |
Проверьте ваш конкретный тулчейн, прежде чем предполагать
Не каждая система сборки параллелизуется одинаково хорошо — некоторые языки/тулчейны исторически имели больше последовательных узких мест (определённые этапы линковки, однопоточные этапы), чем другие. Прежде чем сильно оптимизировать под количество ядер, проверьте, действительно ли сборка вашего конкретного проекта хорошо использует несколько ядер (видно в мониторинге системных ресурсов во время реальной сборки) — оптимизация под параллельное количество ядер, когда ваша сборка на самом деле плохо параллелизуется, тратит впустую бюджет, который мог бы пойти на ОЗУ или хранилище.
Вопрос Intel против AMD для этого конкретного случая использования
Для чистой пропускной способности многоядерной компиляции при данной цене это часто благоприятствует тому чипу, который предлагает больше ядер за деньги в данном поколении — см. наше более широкое сравнение Intel против AMD Ryzen для специфики текущего поколения, поскольку это меняется по циклам продуктов.
Собираете или обновляете машину специально для разработки и хотите второе мнение о приоритетах спецификаций для вашего реального тулчейна? Свяжитесь со мной.
Частые вопросы
Помогает ли больше ОЗУ напрямую скорости компиляции?
Косвенно, но значительно — нехватка ОЗУ во время большой сборки заставляет систему переключаться на медленный своп на основе диска (см. наш [объяснитель по ОЗУ](/blog/how-ram-works-simply)), что может вредить времени компиляции гораздо больше, чем помогло бы умеренное обновление процессора.
Что важнее для компиляции — количество ядер или скорость одного ядра?
Количество ядер важнее для языков/тулчейнов, которые хорошо параллелизуют компиляцию (многие современные системы сборки делают это по умолчанию) — проверьте, действительно ли ваш конкретный тулчейн параллелизуется, прежде чем предполагать, что больше ядер автоматически помогает.
Влияет ли скорость хранилища на время компиляции?
Да, заметно для больших проектов с множеством файлов — быстрое хранилище (см. наше [руководство NVMe против SATA](/blog/nvme-vs-sata-ssd-real-difference)) сокращает время, затрачиваемое на чтение/запись множества промежуточных файлов, которые генерирует большая сборка.