Як змусити Windows працювати так швидко, як Linux, для компіляції C ++?

Я знаю, що це не стільки питання програмування, але це актуально.

Я працюю над досить великим проектом крос-платформ . У Windows я використовую VC ++ 2008. У Linux я використовую gcc. У проекті є близько 40 тис. Файлів. При складанні та пов'язуванні одного і того ж проекту Windows на 10 і 40 разів повільніше, ніж Linux. Як я можу це виправити?

Індивідуальна інкрементальна збірка 20 секунд на Linux та> 3 хвилини в Windows. Чому? Я навіть можу встановити «золотий» лінкер в Linux і отримати цей час до 7 секунд.

Аналогічно git на 10x40 разів швидше в Linux, ніж у Windows.

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

Як простий тест, знайдіть папку з великою кількістю папок і зробіть просту

dir /s > c:\list.txt

на Windows. Зробіть це два рази і раз на другий запуск, щоб він запускався з кеша. Скопіюйте файли в Linux і виконайте 2 еквівалента та час другого запуску.

ls -R > /tmp/list.txt

У мене є 2 робочих станції з точно такими ж характеристиками. HP Z600s з 12 гігами оперативної пам’яті, 8 ядрами при 3,0 ГГц. У папці з ~ 400k файлами Windows займає 40 секунд, Linux займає <1 секунду.

Чи можна встановити налаштування реєстру, щоб пришвидшити Windows? Що дає?

Кілька дещо релевантних посилань, що стосуються часу компіляції, не обов'язково i / o.

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

• Цей /analyseпараметр може негативно вплинути на perf, оскільки він завантажує веб-браузер . (Тут не актуально, але добре знати)

Якщо не з'явиться хакерський засіб для систем Windows, ви не отримаєте більше, ніж партизанські коментарі (що я не буду робити) та спекуляції (що я спробую спробувати).

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

2. Кешування. Я одного разу спробував запустити компіляцію в Linux на диску оперативної пам'яті і виявив, що це повільніше, ніж запустити його на диску, завдяки тому, що ядро ​​піклується про кешування. Це солідний момент продажу для Linux і, можливо, є причиною того, що продуктивність настільки різна.

3. Погані специфікації залежності для Windows. Можливо, специфікації залежності хрому для Windows не такі правильні, як для Linux. Це може призвести до непотрібних компіляцій, коли ви внесете невеликі зміни. Ви можете це підтвердити, використовуючи ту саму ланцюжок інструментів компілятора в Windows.

Кілька ідей:

1. Вимкнути 8,3 імені. Це може бути великим фактором на накопичувачах з великою кількістю файлів і відносно невеликою кількістю папок:fsutil behavior set disable8dot3 1
2. Використовуйте більше папок. На мій досвід, NTFS починає сповільнюватися з більш ніж 1000 файлами в папці.
3. Увімкнути паралельні побудови за допомогою MSBuild; просто додайте перемикач "/ m", і він автоматично запустить одну копію MSBuild на ядро ​​CPU.
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 поведінку встановити disabledlastaccess 1" (перезапуск)

Наскільки я можу сказати, проблема з візуальним c ++ полягає в тому, що оптимізація цього сценарію для команди-компілятора не є пріоритетною. Їх рішення полягає в тому, що ви використовуєте їх попередньо складену функцію заголовка. Це те, що зробили конкретні проекти для Windows. Він не портативний, але працює.

Крім того, у Windows зазвичай є сканери вірусів, а також інструменти відновлення та пошуку системи, які можуть повністю зруйнувати ваші строки збирання, якщо вони відстежують вашу папку buid для вас. монітор resouce windows 7 може допомогти вам помітити його. У мене є відповідь тут із деякими подальшими порадами щодо оптимізації vc ++ строків збирання, якщо вас справді цікавить.

Я особисто виявив, що запускає віртуальну машину Windows на Linux, вдалося вилучити велику повільність IO у Windows, ймовірно, тому, що linux vm робив багато кешування, що сама Windows не була.

Здійснюючи це, я зміг прискорити збірку великого проекту (250 Клот) на C ++, над яким я працював, приблизно від 15 хвилин до приблизно 6 хвилин.

Складність у цьому пов'язана з тим, що 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 - це повернення та пересування між Osterhaus та Selzer http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal. html Ви не бачите подібного, що відбувається в світі Windows. Ви можете побачити постачальників, які налагоджують один одного, але останнім часом це здається набагато рідкіснішим, оскільки інновації здаються на рівні стандартних стандартів.

Ось як я це бачу.

Оновлення: Якщо ви подивитеся на нові ланцюги компіляторів, які виходять з Microsoft, ви будете дуже оптимістичними, оскільки багато з того, що вони роблять, полегшує збереження всього ланцюжка інструментів в оперативній пам’яті і повторює менше роботи. Дуже вражаючі речі.

Поступова зв'язування

Якщо рішення 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 разів, але у нас є багато спільних бібліотек та виконуваних файлів (що зменшує переваги збірки єдності).

Як ви будуєте свій великий проект крос-платформи? Якщо ви використовуєте загальні файли для Linux та Windows, ви можете легко погіршити продуктивність Windows в 10 разів, якщо файли не розроблені для швидкої роботи в Windows.

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

Згідно з GNU складають документацію

.ONESHELL:

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

IMHO - це все щодо продуктивності вводу / виводу диска. Порядок масштабів передбачає, що багато операцій переходять на диск під Windows, тоді як вони обробляються в пам'яті під Linux, тобто Linux кешується краще. Найкращим варіантом під Windows буде переміщення файлів на швидкий диск, сервер або файлову систему. Подумайте про придбання твердотільного диска або переміщення файлів на рамковий диск або швидкий сервер 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 змушує робити це поза коробкою завдяки опції -j, що може бути причиною його швидкості порівняно з Microsoft nmake.

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

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

Перш ніж у мене з’явився великий головний біль, оскільки швидкість збірки знизилася в 10 разів, коли я паралельно відкривав VPN-з'єднання. У цьому випадку всі ці пошукові запити DNS пройшли через VPN.

Це спостереження може бути застосовано і до інших інструментів побудови, не лише на основі MinGW, але воно могло змінитись і в останній версії MinGW.

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

(Win-bash не дуже зручний щодо інтерактивного редагування.)