действительно ли создание из ОЗУ действительно увеличивает скорость?

Question

Я работаю над проектом, который содержит тысячи .cpp файлов, а также тысячи других .h и .hpp, а сборка занимает 28мин работает с SSD.

Мы унаследовали этот проект от другой компании всего несколько недель назад, но просматривая make-файлы, они явно отключили параллельные сборки через фальшивую цель .NOPARALLEL; мы пытаемся выяснить, есть ли у них веская причина.

Худший случай, единственный способ ускорить это - использовать RAM-привод.

Так что я следовал инструкции от Tekrevue и установлены Imdisk, а затем побежал тестов с использованием CrystalDiskMark:

SSD RAM Drive

Я побежал dd с помощью Cygwin и есть значительное увеличение скорости (по крайней мере 3 раза) на диске RAM по сравнению с моим SSD.

Однако мое время сборки меняется не одна минута!

Итак, я подумал: может быть, мой собственный компилятор вызывает некоторый Windows API и вызывает огромное замедление, поэтому я построил fftw из источника на Cygwin.

Я ожидал, что мое использование процессора увеличится до некоторого максимума и останется там на время сборки. Вместо этого мое использование было очень колючим: по одному для каждого скомпилированного файла. Я понимаю, что даже Cygwin по-прежнему должен взаимодействовать с окнами, так что тот факт, что я все еще получил шикарное использование proc, заставляет меня предположить, что это не мой компилятор.

Хорошо. Новая теория: вызов компилятора для каждого файла-источника имеет некоторые огромные накладные расходы в Windows, поэтому я скопировал их из моего журнала сборки и передал 45 файлов моему компилятору и сравнил его с выделением компилятора 45 раз отдельно. Вызов ONCE был быстрее, но всего за 4 секунды для 45 файлов. И я видел такое же «шиповатое» использование процессора, как при вызове компилятора один раз для каждого файла.

Почему я не могу заставить компилятор работать быстрее даже при работе с RAM-диском? Какие накладные расходы?

UPDATE # 1 Commenters говорили, я думаю, что RAM диск вещь вроде ненужные окна BC кэширует входные и выходные файлы в памяти в любом случае. Плюс, возможно, реализация RAM-привода (то есть драйверы) является неоптимальной. Итак, я больше не использую RAM-диск.

Кроме того, люди сказали, что я должен многократно запускать 45-файлную сборку, чтобы удалить накладные расходы для кеширования: я запускал ее 4 раза и каждый раз это было 52secs.

использования процессора (приняты 5 секунд до компиляции завершившихся)

Виртуального использование памяти Когда компилятор выкладывает материал на диск, это на самом деле в памяти кеш первый, правильно? Ну, тогда этот скриншот указывает на то, что IO не проблема, или, скорее, так же быстро, как и моя оперативная память.

Вопрос: Так что, поскольку все в ОЗУ, почему же ЦП% больше больше времени? Есть ли что-нибудь, что я могу сделать, чтобы сделать single-threaded/job build go быстрее? (Помните, что это однопоточная сборка на данный момент)

UPDATE 2 Было предложено ниже, что я должен установить родство, мой компиляция 45-файлы вызов, 1 так, что окна не будут отскакивать вокруг обращения к нескольким ядрам. Результат:

100% одноядерное использование! для того же 52secs

Так это был не жесткий диск, оперативная память или кэш, но CPU это узкое место.

** СПАСИБО ВСЕМ! ** для вашей помощи

======================================================================================================================================================= ===============================

Моя машина: Intel i7-4710MQ @ 2.5GHz, 16GB RAM

Answer 1

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

Теперь, когда вы исключили «диск» и процессор, я ожидаю, что узким местом будет скорость памяти - не для части ввода-вывода RAM-диска (которая, вероятно, уже была в основном насыщена SSD), но и для компиляции сам процесс.

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

В любом случае, это все предположения. Если вам нужен надежный ответ, как обычно, вы должны профиль. Возьмите профайлер пробоотбора от a list like this и идите посмотреть, куда компилятор тратит время. Лично я ожидаю увидеть здоровую дозу промахов в кеше (или даже ошибки страницы, если вы сожгли слишком много RAM для ramdisk), но все может быть.

Answer 2

Чтение исходного кода с диска - очень и очень небольшая часть накладных расходов на компиляцию программного обеспечения. Скорость вашего процессора гораздо более актуальна, так как синтаксический анализ и генерация двоичных файлов являются самой медленной частью процесса.

** Обновление Ваши графики показывают очень загруженный CPU, я не уверен, что вы ожидаете увидеть. Если сборка многопоточная И ваше ядро ​​перестает планировать другие, менее интенсивные потоки, это, безусловно, график занятого процессора.

Answer 3

В вашей трассе показано использование процессора 23%. Ваш процессор имеет 4 реальных ядра (с гиперпотоком, чтобы он выглядел как 8). Таким образом, вы используете ровно одно ядро ​​до его абсолютного максимума (плюс или минус 2%, что, вероятно, является лучшей точностью, чем вы действительно можете ожидать).

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

Если вам нужны существенно более быстрые сборки, вам нужно либо выяснить, что не так с вашими текущими make-файлами, либо написать совершенно новые без проблем, поэтому вы можете поддерживать как частичные, так и параллельные сборки.

Это может нанести вам лот. По сути, все, что вы делаете (ускорение дисков, разгон процессора и т. Д.), В лучшем случае даст незначительные выигрыши (возможно, 20%, если вам действительно повезло, где правильная среда сборки, вероятно, даст хотя бы 20: 1 улучшение для большинства типичных сборок).