Как заставить Windows работать так же быстро, как Linux, для компиляции C ++?

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

Я работаю над довольно крупным кроссплатформенным проектом . В Windows я использую VC ++ 2008. В Linux я использую gcc. В проекте около 40к файлов. Windows в 10-40 раз медленнее, чем Linux при компиляции и компоновке одного и того же проекта. Как я могу это исправить?

Инкрементальная сборка с одним изменением 20 секунд в Linux и> 3 минут в Windows. Зачем? Я даже могу установить «золотой» компоновщик в Linux и сократить это время до 7 секунд.

Точно так же git в 10-40 раз быстрее в Linux, чем в Windows.

В случае git возможно, что git не использует Windows оптимальным образом, но VC ++? Можно подумать, что Microsoft захочет сделать своих разработчиков максимально продуктивными, и более быстрая компиляция будет иметь большое значение для этого. Может быть, они пытаются подтолкнуть разработчиков к C #?

В качестве простого теста найдите папку с большим количеством подпапок и выполните простой

dir /s > c:\list.txt

в Windows. Сделайте это дважды и рассчитайте время второго запуска, чтобы он запускался из кеша. Скопируйте файлы в Linux и выполните 2 эквивалентных запуска и время второго запуска.

ls -R > /tmp/list.txt

У меня две рабочие станции с одинаковыми характеристиками. HP Z600 с 12 ГБ оперативной памяти, 8 ядер на 3,0 ГГц. В папке с ~ 400 КБ файлов Windows занимает 40 секунд, Linux - менее 1 секунды.

Есть ли параметр реестра, который я могу настроить для ускорения работы Windows? Что дает?

Несколько слегка релевантных ссылок, относящихся ко времени компиляции, не обязательно ввода-вывода.

• По-видимому , в Windows 10 (не в Windows 7) есть проблема, заключающаяся в том, что закрытие процесса удерживает глобальную блокировку . Эта проблема возникает при компиляции с несколькими ядрами и, следовательно, с несколькими процессами.

• Этот /analyseпараметр может отрицательно повлиять на производительность, поскольку он загружает веб-браузер . (Здесь не актуально, но полезно знать)

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

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

2. Кеширование. Однажды я попытался запустить компиляцию в Linux на RAM-диске и обнаружил, что это медленнее, чем запуск на диске, благодаря тому, как ядро ​​заботится о кэшировании. Это веский аргумент в пользу Linux и может быть причиной того, что производительность так сильно отличается.

3. Плохая спецификация зависимости в Windows. Возможно, спецификации зависимости хрома для Windows не так верны, как для Linux. Это может привести к ненужным компиляциям при внесении небольших изменений. Возможно, вы сможете проверить это, используя ту же цепочку инструментов компилятора в Windows.

Несколько идей:

1. Отключить имена 8.3. Это может иметь большое значение для дисков с большим количеством файлов и относительно небольшим количеством папок:fsutil behavior set disable8dot3 1
2. Используйте больше папок. По моему опыту, NTFS начинает тормозить с более чем 1000 файлов в папке.
3. Включите параллельные сборки с MSBuild; просто добавьте переключатель «/ m», и он автоматически запустит одну копию MSBuild для каждого ядра процессора.
4. Поместите свои файлы на SSD - очень помогает при случайном вводе-выводе.
5. Если ваш средний размер файла намного превышает 4 КБ, подумайте о перестройке файловой системы с большим размером кластера, который примерно соответствует вашему среднему размеру файла.
6. Убедитесь, что файлы были дефрагментированы. Фрагментированные файлы вызывают много обращений к диску, что может стоить вам более 40 раз. Используйте утилиту contig от sysinternals или встроенный дефрагментатор Windows.
7. Если ваш средний размер файла невелик, а раздел, в котором вы находитесь, относительно заполнен, возможно, вы работаете с фрагментированной MFT, что плохо сказывается на производительности. Кроме того, файлы размером менее 1 КБ хранятся непосредственно в MFT. Упомянутая выше утилита contig может помочь, или вам может потребоваться увеличить размер MFT. Следующая команда удвоит его до 25% от объема: fsutil behavior set mftzone 2Измените последнее число на 3 или 4, чтобы увеличить размер на дополнительные 12,5%. После выполнения команды перезагрузитесь, а затем создайте файловую систему.
8. Отключить время последнего доступа: fsutil behavior set disablelastaccess 1
9. Отключить службу индексирования
10. Отключите антивирусное и антишпионское ПО или, по крайней мере, установите игнорирование соответствующих папок.
11. Поместите свои файлы на другой физический диск, отличный от ОС и файла подкачки. Использование отдельного физического диска позволяет Windows использовать параллельный ввод-вывод для обоих дисков.
12. Посмотрите на флаги вашего компилятора. Компилятор Windows C ++ имеет множество опций; убедитесь, что вы используете только те, которые вам действительно нужны.
13. Попробуйте увеличить объем памяти, который ОС использует для буферов выгружаемого пула (сначала убедитесь, что у вас достаточно ОЗУ): fsutil behavior set memoryusage 2
14. Проверьте журнал ошибок Windows, чтобы убедиться, что у вас не возникают случайные ошибки диска.
15. Взгляните на счетчики производительности, связанные с физическим диском, чтобы узнать, насколько загружены ваши диски. Большая длина очереди или большое время на передачу - плохие признаки.
16. Первые 30% разделов диска намного быстрее, чем остальной диск, с точки зрения времени необработанной передачи. Более узкие разделы также помогают минимизировать время поиска.
17. Вы используете RAID? В таком случае вам может потребоваться оптимизировать выбор типа RAID (RAID-5 плохо подходит для операций с большим объемом записи, таких как компиляция).
18. Отключите все службы, которые вам не нужны
19. Папки дефрагментации: скопируйте все файлы на другой диск (только файлы), удалите исходные файлы, скопируйте все папки на другой диск (только пустые папки), затем удалите исходные папки, дефрагментируйте исходный диск, сначала скопируйте структуру папок обратно , затем скопируйте файлы. Когда Windows создает большие папки по одному файлу за раз, папки становятся фрагментированными и медленными. ("contig" здесь тоже должен помочь)
20. Если вы ограничены вводом-выводом и у вас есть свободные циклы ЦП, попробуйте включить сжатие диска. Он может обеспечить значительное ускорение для файлов с высокой степенью сжатия (например, исходного кода) с некоторыми затратами на процессор.

NTFS всегда экономит время доступа к файлам. Вы можете попробовать отключить его: «fsutil behavior set disablelastaccess 1» (перезапуск)

Проблема с Visual C ++, насколько я могу судить, заключается в том, что оптимизация этого сценария не является приоритетом для команды компиляторов. Их решение состоит в том, что вы используете их предварительно скомпилированный заголовок. Это то, что сделали конкретные проекты Windows. Он не портативный, но работает.

Кроме того, в Windows у вас обычно есть антивирусные сканеры, а также инструменты восстановления системы и поиска, которые могут полностью испортить время сборки, если они будут отслеживать вашу папку сборки за вас. Windows 7 Resouce Monitor поможет вам обнаружить это. У меня есть ответ с некоторыми дополнительными советами по оптимизации времени сборки vc ++, если вам действительно интересно.

Трудность с этим связана с тем, что C ++ имеет тенденцию распространяться и процесс компиляции на множество небольших отдельных файлов. В этом Linux хорош, а Windows - нет. Если вы хотите создать действительно быстрый компилятор C ++ для Windows, постарайтесь сохранить все в ОЗУ и как можно меньше касаться файловой системы.

Таким же образом вы сделаете более быструю цепочку компиляции Linux C ++, но в Linux это менее важно, потому что файловая система уже выполняет большую часть этой настройки за вас.

Причина этого кроется в культуре Unix: исторически производительность файловой системы была гораздо более приоритетной в мире Unix, чем в Windows. Нельзя сказать, что это не было приоритетом в Windows, просто в Unix это был более высокий приоритет.

1. Доступ к исходному коду.

   Вы не можете изменить то, что не можете контролировать. Отсутствие доступа к исходному коду Windows NTFS означает, что большая часть усилий по повышению производительности была направлена ​​на улучшение оборудования. То есть, если производительность низкая, вы можете обойти проблему, улучшив оборудование: шину, носитель данных и так далее. Вы можете сделать так много только в том случае, если вам нужно обойти проблему, а не исправить ее.

   Доступ к исходному коду Unix (даже до открытия исходного кода) был более распространен. Следовательно, если вы хотите повысить производительность, вы должны сначала решить эту проблему в программном обеспечении (дешевле и проще), а затем в оборудовании.

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

2. Unix имеет тенденцию к созданию множества маленьких файлов; Windows стремится к нескольким (или одному) большим файлам.

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

   В результате Unix имеет высоко оптимизированные системные вызовы для открытия и закрытия файлов, сканирования каталогов и т. Д. История исследовательских работ по Unix насчитывает десятилетия оптимизации файловой системы, в ходе которой было уделено много внимания улучшению доступа к каталогам (поиск и полное сканирование каталогов), первоначального открытия файлов и т. Д.

   Приложения Windows, как правило, открывают один большой файл, держат его открытым в течение долгого времени, а после завершения закрывают. Подумайте о MS-Word. msword.exe (или что-то еще) открывает файл один раз и добавляет его на несколько часов, обновляет внутренние блоки и так далее. Оптимизация открытия файла приведет к потере времени.

   История тестирования и оптимизации Windows связана с тем, насколько быстро можно читать или записывать длинные файлы. Вот что оптимизируется.

   К сожалению, разработка программного обеспечения склоняется к первой ситуации. Черт возьми, лучшая система обработки текстов для Unix (TeX / LaTeX) поощряет вас помещать каждую главу в отдельный файл и # включать их все вместе.

3. Unix ориентирован на высокую производительность; Windows ориентирована на взаимодействие с пользователем

   Unix запускается в серверной: нет пользовательского интерфейса. Единственное, что видят пользователи, - это скорость. Поэтому скорость - приоритет.

   Windows запускалась на рабочем столе: пользователей заботит только то, что они видят, и они видят пользовательский интерфейс. Следовательно, на улучшение пользовательского интерфейса тратится больше энергии, чем на производительность.

4. Экосистема Windows зависит от запланированного устаревания. Зачем оптимизировать программное обеспечение, если до нового оборудования осталось всего год или два?

   Я не верю в теории заговора, но если бы верил, я бы отметил, что в культуре Windows меньше стимулов для повышения производительности. Бизнес-модели Windows зависят от людей, покупающих новые машины, как часы. (Вот почему на котировки акций тысяч компаний влияет задержка поставки операционной системы MS или пропуск даты выпуска микросхемы Intel.) Это означает, что есть стимул решать проблемы производительности, говоря людям покупать новое оборудование; не за счет улучшения реальной проблемы: медленных операционных систем. Unix пришла из академических кругов, где бюджет ограничен, и вы можете получить докторскую степень, изобретя новый способ ускорить файловые системы; редко кто-то из академических кругов получает баллы за решение проблемы путем выдачи заказа на поставку.

   Кроме того, поскольку Unix является открытым исходным кодом (даже если его не было, каждый имел доступ к исходному тексту), любой скучающий аспирант может прочитать код и прославиться, улучшив его. Этого не происходит в Windows (у MS действительно есть программа, которая дает ученым доступ к исходному коду Windows, но ею редко пользуются). Взгляните на эту подборку документов о производительности, связанных с Unix: http://www.eecs.harvard.edu/margo/papers/ или посмотрите историю статей Остерхауса, Генри Спенсера или других. Черт возьми, одним из крупнейших (и наиболее приятных для просмотра) споров в истории Unix был спор между Остерхаусом и Зельцером http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal. html Вы не увидите такого рода вещей в мире Windows. Вы можете увидеть, как поставщики напирают друг на друга, но в последнее время это, похоже, стало намного реже, поскольку все нововведения, по всей видимости, находятся на уровне органов стандартизации.

Вот как я это вижу.

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

Я лично обнаружил, что запуск виртуальной машины Windows на linux позволил устранить большую часть медленного ввода-вывода в Windows, вероятно, потому, что linux vm выполнял много кэширования, чего не было в самой Windows.

Благодаря этому я смог сократить время компиляции большого (250Kloc) проекта C ++, над которым я работал, с примерно 15 минут до примерно 6 минут.

Инкрементное связывание

Если решение VC 2008 настроено как несколько проектов с выходными файлами .lib, вам необходимо установить «Использовать входы зависимостей библиотеки»; это делает ссылку компоновщика непосредственно на файлы .obj, а не на .lib. (И фактически делает его постепенным связыванием.)

Производительность обхода каталогов

Немного несправедливо сравнивать сканирование каталогов на исходном компьютере со сканированием вновь созданного каталога с такими же файлами на другом компьютере. Если вам нужен эквивалентный тест, вам, вероятно, следует сделать еще одну копию каталога на исходной машине. (Это все еще может быть медленным, но это может быть связано с множеством причин: фрагментацией диска, короткими именами файлов, фоновыми службами и т. Д.) Хотя я думаю, что проблемы производительности dir /sбольше связаны с записью вывода, чем с измерением фактического файла производительность обхода. Даже dir /s /b > nulна моей машине с огромным каталогом работает медленно.

Я почти уверен, что это связано с файловой системой. Я работаю над кроссплатформенным проектом для Linux и Windows, где весь код является общим, за исключением случаев, когда платформенно-зависимый код абсолютно необходим. Мы используем Mercurial, а не git, поэтому «Linuxness» git не применяется. Внесение изменений из центрального репозитория в Windows занимает вечность по сравнению с Linux, но я должен сказать, что наши машины с Windows 7 работают намного лучше, чем машины с Windows XP. Компиляция кода после этого в VS 2008 еще хуже. Дело не только в hg; CMake также работает намного медленнее в Windows, и оба этих инструмента используют файловую систему больше, чем что-либо еще.

Проблема настолько серьезна, что большинство наших разработчиков, работающих в среде Windows, больше даже не утруждают себя инкрементными сборками - они обнаруживают, что сборка единства выполняется быстрее.

Кстати, если вы хотите резко снизить скорость компиляции в Windows, я бы предложил вышеупомянутую сборку единства. Трудно правильно реализовать в системе сборки (я сделал это для нашей команды в CMake), но когда это сделано, автоматически ускоряет работу наших серверов непрерывной интеграции. В зависимости от того, сколько двоичных файлов выдает ваша система сборки, вы можете получить улучшение на 1–2 порядка. Ваш пробег может отличаться. В нашем случае я думаю, что это ускорило сборку Linux втрое, а сборку Windows примерно в 10 раз, но у нас много общих библиотек и исполняемых файлов (что снижает преимущества единой сборки).

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

Я только что исправил некоторые make-файлы кроссплатформенного проекта, используя общие (GNU) make-файлы для Linux и Windows. Make запускает sh.exeпроцесс для каждой строки рецепта, вызывая разницу в производительности между Windows и Linux!

Согласно документации GNU make

.ОНЕШЕЛЛ:

должен решить проблему, но эта функция (в настоящее время) не поддерживается для Windows make. Так что переписывание рецептов в отдельные логические строки (например, добавление; \ или \ в конец строк текущего редактора) сработало очень хорошо!

ИМХО, все дело в производительности дискового ввода-вывода. По порядку величины предполагается, что многие операции выполняются на диске под Windows, тогда как под Linux они выполняются в памяти, т.е. Linux лучше кэширует. Лучшим вариантом под Windows будет перемещение файлов на быстрый диск, сервер или файловую систему. Рассмотрите возможность покупки твердотельного накопителя или перемещения файлов на RAM-диск или быстрый сервер NFS.

Я провел тесты обхода каталогов, и результаты очень близки к заявленному времени компиляции, предполагая, что это не имеет никакого отношения к времени обработки ЦП или алгоритмам компилятора / компоновщика.

Измеренное время, как предложено выше при обходе дерева каталогов хрома:

• Windows Home Premium 7 (8 ГБ ОЗУ) в NTFS: 32 секунды
• Ubuntu 11.04 Linux (2 ГБ ОЗУ) в NTFS: 10 секунд
• Ubuntu 11.04 Linux (2 ГБ ОЗУ) на ext4: 0,6 секунды

Для тестов вытащил исходники хрома (оба под win / linux)

git clone http://github.com/chromium/chromium.git 
cd chromium
git checkout remotes/origin/trunk 

Чтобы измерить время, которое я бежал

ls -lR > ../list.txt ; time ls -lR > ../list.txt # bash
dir -Recurse > ../list.txt ; (measure-command { dir -Recurse > ../list.txt }).TotalSeconds  #Powershell

Я отключил временные метки доступа, свой антивирусный сканер и увеличил настройки кеш-менеджера под Windows (> 2 ГБ ОЗУ) - все без каких-либо заметных улучшений. Дело в том, что Linux «из коробки» работал в 50 раз лучше, чем Windows с четвертью ОЗУ.

Для тех, кто хочет утверждать, что цифры неверны - по какой-либо причине - попробуйте и опубликуйте свои выводы.

Попробуйте использовать jom вместо nmake

Получите здесь: https://github.com/qt-labs/jom

Дело в том, что nmake использует только одно из ваших ядер, jom - это клон nmake, который использует многоядерные процессоры.

GNU make делает это из коробки благодаря опции -j, что может быть причиной его скорости по сравнению с Microsoft nmake.

jom работает, выполняя параллельно разные команды make на разных процессорах / ядрах. Попробуйте сами почувствуйте разницу!

Я хочу добавить только одно наблюдение с использованием Gnu make и других инструментов из инструментов MinGW в Windows: они, похоже, разрешают имена хостов, даже если инструменты не могут даже общаться через IP. Я предполагаю, что это вызвано какой-то процедурой инициализации среды выполнения MinGW. Использование локального DNS-прокси помогло мне улучшить скорость компиляции с помощью этих инструментов.

Раньше у меня сильно болела голова, потому что скорость сборки упала примерно в 10 раз, когда я открывал VPN-соединение параллельно. В этом случае все эти DNS-запросы проходили через VPN.

Это наблюдение может также относиться к другим инструментам сборки, не только на основе MinGW, и тем временем оно могло быть изменено в последней версии MinGW.

Недавно я мог заархивировать другой способ ускорить компиляцию примерно на 10% в Windows с помощью Gnu make, заменив mingw bash.exe версией из win-bash

(Win-bash не очень удобен для интерактивного редактирования.)