Comment faire en sorte que Windows aille aussi vite que Linux pour la compilation de C ++?

Je sais que ce n'est pas tant une question de programmation, mais c'est pertinent.

Je travaille sur un projet multiplateforme assez important . Sous Windows, j'utilise VC ++ 2008. Sous Linux, j'utilise gcc. Il y a environ 40k fichiers dans le projet. Windows est 10x à 40x plus lent que Linux lors de la compilation et de la liaison du même projet. Comment puis-je résoudre ce problème?

Une seule modification incrémentielle de 20 secondes sous Linux et> 3 minutes sous Windows. Pourquoi? Je peux même installer l'éditeur de liens «or» sous Linux et réduire ce temps à 7 secondes.

De même, git est 10x à 40x plus rapide sous Linux que Windows.

Dans le cas de git, il est possible que git n'utilise pas Windows de manière optimale mais VC ++? On pourrait penser que Microsoft voudrait rendre ses propres développeurs aussi productifs que possible et une compilation plus rapide y contribuerait grandement. Peut-être essaient-ils d'encourager les développeurs à utiliser C #?

Comme simple test, trouvez un dossier avec beaucoup de sous-dossiers et faites un simple

dir /s > c:\list.txt

sur Windows. Faites-le deux fois et chronométrez la deuxième exécution pour qu'elle s'exécute à partir du cache. Copiez les fichiers sur Linux et effectuez les 2 exécutions équivalentes et chronométrez la deuxième exécution.

ls -R > /tmp/list.txt

J'ai 2 postes de travail avec exactement les mêmes spécifications. HP Z600s avec 12gig de RAM, 8 cœurs à 3.0ghz. Sur un dossier contenant environ 400 000 fichiers, Windows prend 40 secondes, Linux prend <1 seconde.

Existe-t-il un paramètre de registre que je peux définir pour accélérer Windows? Ce qui donne?

Quelques liens légèrement pertinents, pertinents pour les temps de compilation, pas nécessairement d'entrées / sorties.

• Apparemment, il y a un problème dans Windows 10 (pas dans Windows 7) selon lequel la fermeture d'un processus détient un verrou global . Lors de la compilation avec plusieurs cœurs et donc plusieurs processus, ce problème survient.

• L' /analyseoption peut nuire à la performance car elle charge un navigateur Web . (Pas pertinent ici mais bon à savoir)

À moins qu'un hacker hardcore des systèmes Windows ne se présente, vous n'obtiendrez pas plus que des commentaires partisans (ce que je ne ferai pas) et des spéculations (ce que je vais essayer).

1. Système de fichiers - Vous devriez essayer les mêmes opérations (y compris le dir) sur le même système de fichiers. Je suis tombé sur ce qui compare quelques systèmes de fichiers pour divers paramètres.

2. Mise en cache. Une fois, j'ai essayé d'exécuter une compilation sous Linux sur un disque RAM et j'ai trouvé que c'était plus lent que de l'exécuter sur disque grâce à la façon dont le noyau s'occupe de la mise en cache. C'est un argument de vente solide pour Linux et pourrait être la raison pour laquelle les performances sont si différentes.

3. Mauvaises spécifications de dépendance sous Windows. Peut-être que les spécifications de dépendance de chrome pour Windows ne sont pas aussi correctes que pour Linux. Cela peut entraîner des compilations inutiles lorsque vous apportez une petite modification. Vous pourrez peut-être valider cela à l'aide de la même chaîne d'outils du compilateur sous Windows.

Quelques idées:

1. Désactivez les noms 8.3. Cela peut être un facteur important sur les lecteurs avec un grand nombre de fichiers et un nombre relativement petit de dossiers:fsutil behavior set disable8dot3 1
2. Utilisez plus de dossiers. D'après mon expérience, NTFS commence à ralentir avec plus d'environ 1000 fichiers par dossier.
3. Activez les versions parallèles avec MSBuild; ajoutez simplement le commutateur "/ m", et il démarrera automatiquement une copie de MSBuild par cœur de processeur.
4. Mettez vos fichiers sur un SSD - aide énormément pour les E / S aléatoires.
5. Si la taille moyenne de votre fichier est bien supérieure à 4 Ko, envisagez de reconstruire le système de fichiers avec une taille de cluster plus grande qui correspond à peu près à votre taille de fichier moyenne.
6. Assurez-vous que les fichiers ont été défragmentés. Les fichiers fragmentés provoquent de nombreuses recherches sur le disque, ce qui peut vous coûter un facteur de 40+ en débit. Utilisez l'utilitaire "contig" de sysinternals ou le défragmenteur Windows intégré.
7. Si la taille moyenne de votre fichier est petite et que la partition sur laquelle vous vous trouvez est relativement pleine, il est possible que vous exécutiez avec un MFT fragmenté, ce qui est mauvais pour les performances. En outre, les fichiers inférieurs à 1K sont stockés directement dans le MFT. L'utilitaire "contig" mentionné ci-dessus peut vous aider, ou vous devrez peut-être augmenter la taille MFT. La commande suivante multipliera, à 25% du volume: fsutil behavior set mftzone 2Change le dernier numéro à 3 ou 4 pour augmenter la taille par incréments supplémentaires de 12,5%. Après avoir exécuté la commande, redémarrez puis créez le système de fichiers.
8. Désactivez l'heure du dernier accès: fsutil behavior set disablelastaccess 1
9. Désactiver le service d'indexation
10. Désactivez vos logiciels antivirus et anti-spyware, ou au moins définissez les dossiers concernés à ignorer.
11. Placez vos fichiers sur un lecteur physique différent du système d'exploitation et du fichier d'échange. L'utilisation d'un lecteur physique distinct permet à Windows d'utiliser des E / S parallèles sur les deux lecteurs.
12. Jetez un œil à vos indicateurs de compilateur. Le compilateur Windows C ++ a une tonne d'options; assurez-vous de n'utiliser que ceux dont vous avez vraiment besoin.
13. Essayez d'augmenter la quantité de mémoire utilisée par le système d'exploitation pour les tampons de pool paginé (assurez-vous d'abord que vous disposez de suffisamment de RAM): fsutil behavior set memoryusage 2
14. Vérifiez le journal des erreurs Windows pour vous assurer que vous ne rencontrez pas d'erreurs de disque occasionnelles.
15. Jetez un œil aux compteurs de performances liés aux disques physiques pour voir à quel point vos disques sont occupés. Les longues files d'attente ou les longs délais par transfert sont de mauvais signes.
16. Les 30 premiers% des partitions de disque sont beaucoup plus rapides que le reste du disque en termes de temps de transfert brut. Des partitions plus étroites aident également à minimiser les temps de recherche.
17. Utilisez-vous RAID? Si tel est le cas, vous devrez peut-être optimiser votre choix de type de RAID (RAID-5 est mauvais pour les opérations gourmandes en écriture comme la compilation)
18. Désactivez tous les services dont vous n'avez pas besoin
19. Défragmenter les dossiers: copiez tous les fichiers sur un autre lecteur (uniquement les fichiers), supprimez les fichiers d'origine, copiez tous les dossiers sur un autre lecteur (uniquement les dossiers vides), puis supprimez les dossiers d'origine, défragmentez le lecteur d'origine, copiez d'abord la structure des dossiers , puis copiez les fichiers. Lorsque Windows crée de gros dossiers un fichier à la fois, les dossiers finissent par être fragmentés et lents. ("contig" devrait aider ici aussi)
20. Si vous êtes lié aux E / S et que vous avez des cycles de processeur à perdre, essayez d'activer la compression de disque. Il peut fournir des accélérations significatives pour les fichiers hautement compressibles (comme le code source), avec un certain coût en CPU.

NTFS enregistre le temps d'accès aux fichiers à chaque fois. Vous pouvez essayer de le désactiver: "fsutil behavior set disablelastaccess 1" (redémarrer)

Le problème avec Visual C ++ est, pour autant que je sache, que ce n'est pas une priorité pour l'équipe du compilateur d'optimiser ce scénario. Leur solution est que vous utilisez leur fonction d'en-tête précompilée. C'est ce qu'ont fait des projets spécifiques à Windows. Ce n'est pas portable, mais cela fonctionne.

De plus, sur Windows, vous avez généralement des antivirus, ainsi que des outils de restauration et de recherche du système qui peuvent ruiner complètement vos temps de construction s'ils surveillent votre dossier Buid pour vous. le moniteur de ressources Windows 7 peut vous aider à le repérer. J'ai une réponse ici avec quelques conseils supplémentaires pour optimiser les temps de construction de vc ++ si vous êtes vraiment intéressé.

J'ai personnellement trouvé que l'exécution d'une machine virtuelle Windows sur Linux a réussi à supprimer une grande partie de la lenteur des E / S dans Windows, probablement parce que la machine virtuelle Linux faisait beaucoup de mise en cache que Windows lui-même ne faisait pas.

En faisant cela, j'ai pu accélérer les temps de compilation d'un grand projet C ++ (250Kloc) sur lequel je travaillais de 15 minutes à environ 6 minutes.

La difficulté à faire cela est due au fait que C ++ a tendance à se répandre et le processus de compilation sur de nombreux petits fichiers individuels. C'est quelque chose pour quoi Linux est bon et Windows n'est pas. Si vous voulez créer un compilateur C ++ très rapide pour Windows, essayez de tout garder dans la RAM et touchez le moins possible le système de fichiers.

C'est aussi ainsi que vous allez créer une chaîne de compilation Linux C ++ plus rapide, mais c'est moins important sous Linux car le système de fichiers effectue déjà une grande partie de ce réglage pour vous.

La raison en est due à la culture Unix: Historiquement, les performances du système de fichiers ont été une priorité beaucoup plus élevée dans le monde Unix que dans Windows. Cela ne veut pas dire que cela n'a pas été une priorité sous Windows, mais simplement que sous Unix, cela a été une priorité plus élevée.

1. Accès au code source.

   Vous ne pouvez pas changer ce que vous ne pouvez pas contrôler. Le manque d'accès au code source de Windows NTFS signifie que la plupart des efforts pour améliorer les performances ont été réalisés grâce à des améliorations matérielles. Autrement dit, si les performances sont lentes, vous contournez le problème en améliorant le matériel: le bus, le support de stockage, etc. Vous ne pouvez faire beaucoup si vous devez contourner le problème et non le résoudre.

   L'accès au code source Unix (même avant l'open source) était plus répandu. Par conséquent, si vous vouliez améliorer les performances, vous vous en occuperiez d'abord dans le logiciel (moins cher et plus facile) et ensuite dans le matériel.

   En conséquence, de nombreuses personnes dans le monde ont obtenu leur doctorat en étudiant le système de fichiers Unix et en trouvant de nouvelles façons d'améliorer les performances.

2. Unix a tendance à utiliser de nombreux petits fichiers; Windows a tendance à utiliser quelques gros fichiers (ou un seul).

   Les applications Unix ont tendance à traiter de nombreux petits fichiers. Pensez à un environnement de développement logiciel: de nombreux petits fichiers sources, chacun ayant son propre objectif. La dernière étape (liaison) crée un gros fichier mais c'est un petit pourcentage.

   En conséquence, Unix a des appels système hautement optimisés pour l'ouverture et la fermeture de fichiers, l'analyse des répertoires, etc. L'histoire des documents de recherche Unix couvre des décennies d'optimisations du système de fichiers qui ont beaucoup réfléchi à l'amélioration de l'accès aux répertoires (recherches et analyses de répertoires complets), à l'ouverture initiale des fichiers, etc.

   Les applications Windows ont tendance à ouvrir un gros fichier, à le maintenir ouvert pendant longtemps, à le fermer une fois terminé. Pensez à MS-Word. msword.exe (ou autre) ouvre le fichier une fois et l'ajoute pendant des heures, met à jour les blocs internes, etc. L'intérêt d'optimiser l'ouverture du fichier serait une perte de temps.

   L'histoire de l'analyse comparative et de l'optimisation de Windows porte sur la vitesse à laquelle on peut lire ou écrire de longs fichiers. C'est ce qui est optimisé.

   Malheureusement, le développement de logiciels a évolué vers la première situation. Heck, le meilleur système de traitement de texte pour Unix (TeX / LaTeX) vous encourage à mettre chaque chapitre dans un fichier différent et à les #inclure tous ensemble.

3. Unix se concentre sur la haute performance; Windows se concentre sur l'expérience utilisateur

   Unix a démarré dans la salle des serveurs: pas d'interface utilisateur. La seule chose que les utilisateurs voient, c'est la vitesse. Par conséquent, la vitesse est une priorité.

   Windows a démarré sur le bureau: les utilisateurs ne se soucient que de ce qu'ils voient et ils voient l'interface utilisateur. Par conséquent, plus d'énergie est dépensée pour améliorer l'interface utilisateur que pour les performances.

4. L'écosystème Windows dépend de l'obsolescence planifiée. Pourquoi optimiser les logiciels alors que le nouveau matériel est dans un an ou deux?

   Je ne crois pas aux théories du complot, mais si je le faisais, je soulignerais que dans la culture Windows, il y a moins d'incitations à améliorer les performances. Les modèles commerciaux Windows dépendent de l’achat de nouvelles machines telles que des roulettes. (C'est pourquoi le cours des actions de milliers d'entreprises est affecté si MS expédie un système d'exploitation en retard ou si Intel manque une date de sortie de puce.). Cela signifie qu'il existe une incitation à résoudre les problèmes de performances en demandant aux gens d'acheter du nouveau matériel; pas en améliorant le vrai problème: la lenteur des systèmes d'exploitation. Unix vient d'universités où le budget est serré et vous pouvez obtenir votre doctorat en inventant une nouvelle façon de rendre les systèmes de fichiers plus rapides; Un universitaire obtient rarement des points pour résoudre un problème en émettant un bon de commande.

   De plus, comme Unix est open source (même quand ce n'était pas le cas, tout le monde avait accès à la source) tout doctorant ennuyé peut lire le code et devenir célèbre en l'améliorant. Cela ne se produit pas sous Windows (MS a un programme qui donne aux universitaires l'accès au code source de Windows, il est rarement utilisé). Regardez cette sélection d'articles de performance liés à Unix: http://www.eecs.harvard.edu/margo/papers/ ou consultez l'historique des articles d'Osterhaus, Henry Spencer ou autres. Heck, l'un des débats les plus importants (et les plus agréables à regarder) de l'histoire d'Unix a été le va-et-vient entre Osterhaus et Selzer http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal. html Vous ne voyez pas ce genre de chose se produire dans le monde Windows. Vous verrez peut-être des fournisseurs s'unir les uns les autres, mais cela semble être beaucoup plus rare ces derniers temps, car l'innovation semble se situer au niveau de l'organisme de normalisation.

Voilà comment je le vois.

Mise à jour: Si vous regardez les nouvelles chaînes de compilateurs qui sortent de Microsoft, vous serez très optimiste car une grande partie de ce qu'ils font facilite la conservation de l'ensemble de la chaîne d'outils en RAM et répète moins de travail. Des trucs très impressionnants.

Liaison incrémentale

Si la solution VC 2008 est configurée comme plusieurs projets avec des sorties .lib, vous devez définir «Utiliser les entrées de dépendance de bibliothèque»; cela fait le lien directement avec les fichiers .obj plutôt qu'avec le .lib. (Et en fait un lien incrémentiel.)

Performances de traversée de répertoire

Il est un peu injuste de comparer l'exploration de répertoires sur la machine d'origine avec l'analyse d'un répertoire nouvellement créé avec les mêmes fichiers sur une autre machine. Si vous voulez un test équivalent, vous devriez probablement faire une autre copie du répertoire sur la machine source. (Cela peut encore être lent, mais cela pourrait être dû à un certain nombre de choses: fragmentation du disque, noms de fichiers courts, services d'arrière-plan, etc.) Bien que je pense que les problèmes de performance pour dir /sont plus à voir avec l'écriture de la sortie que la mesure du fichier réel performances de traversée. Même dir /s /b > nulest lent sur ma machine avec un énorme répertoire.

Je suis presque sûr que c'est lié au système de fichiers. Je travaille sur un projet multiplateforme pour Linux et Windows où tout le code est commun sauf là où le code dépendant de la plateforme est absolument nécessaire. Nous utilisons Mercurial, pas git, donc la "Linuxness" de git ne s'applique pas. Récupérer des modifications depuis le référentiel central prend une éternité sur Windows par rapport à Linux, mais je dois dire que nos machines Windows 7 font beaucoup mieux que celles de Windows XP. Compiler le code après cela est encore pire sur VS 2008. Ce n'est pas seulement hg; CMake fonctionne également beaucoup plus lentement sous Windows, et ces deux outils utilisent le système de fichiers plus que toute autre chose.

Le problème est si grave que la plupart de nos développeurs qui travaillent dans un environnement Windows ne prennent même plus la peine de faire des builds incrémentiels - ils trouvent que faire une build unitaire à la place est plus rapide.

Incidemment, si vous souhaitez réduire considérablement la vitesse de compilation dans Windows, je suggérerais la construction d'unité susmentionnée. C'est difficile à mettre en œuvre correctement dans le système de construction (je l'ai fait pour notre équipe dans CMake), mais une fois cela fait, cela accélère automatiquement les choses pour nos serveurs d'intégration continue. En fonction du nombre de binaires que votre système de construction crache, vous pouvez obtenir une amélioration de 1 à 2 ordres de grandeur. Votre kilométrage peut varier. Dans notre cas, je pense que cela a multiplié par trois les versions de Linux et celle de Windows par environ un facteur de 10, mais nous avons beaucoup de bibliothèques et d'exécutables partagés (ce qui diminue les avantages d'une construction unitaire).

Comment construisez-vous votre grand projet multiplateforme? Si vous utilisez des makefiles courants pour Linux et Windows, vous pouvez facilement dégrader les performances de Windows d'un facteur 10 si les makefiles ne sont pas conçus pour être rapides sous Windows.

Je viens de corriger quelques makefiles d'un projet multiplateforme en utilisant des makefiles communs (GNU) pour Linux et Windows. Make démarre un sh.exeprocessus pour chaque ligne d'une recette causant la différence de performances entre Windows et Linux!

Selon la documentation GNU make

.ONESHELL:

devrait résoudre le problème, mais cette fonctionnalité n'est (actuellement) pas prise en charge pour Windows make. Donc, réécrire les recettes sur des lignes logiques uniques (par exemple en ajoutant; \ ou \ à la fin des lignes actuelles de l'éditeur) fonctionnait très bien!

À mon humble avis, tout est question de performances d'E / S de disque. L'ordre de grandeur suggère que beaucoup d'opérations sont effectuées sur le disque sous Windows alors qu'elles sont gérées en mémoire sous Linux, c'est-à-dire que Linux met mieux en cache. Votre meilleure option sous Windows sera de déplacer vos fichiers sur un disque, un serveur ou un système de fichiers rapide. Pensez à acheter un disque SSD ou à déplacer vos fichiers vers un disque RAM ou un serveur NFS rapide.

J'ai exécuté les tests de traversée des répertoires et les résultats sont très proches des temps de compilation rapportés, ce qui suggère que cela n'a rien à voir avec les temps de traitement du processeur ou les algorithmes du compilateur / éditeur de liens.

Temps mesurés comme suggéré ci-dessus dans l'arborescence du répertoire chrome:

• Windows Home Premium 7 (8 Go de RAM) sur NTFS: 32 secondes
• Ubuntu 11.04 Linux (2 Go de RAM) sur NTFS: 10 secondes
• Ubuntu 11.04 Linux (2 Go de RAM) sur ext4: 0,6 seconde

Pour les tests, j'ai tiré les sources de chrome (les deux sous win / linux)

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

Pour mesurer le temps que j'ai couru

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

J'ai désactivé les horodatages d'accès, mon antivirus et augmenté les paramètres du gestionnaire de cache sous Windows (> 2 Go de RAM) - le tout sans aucune amélioration notable. Le fait est que Linux prêt à l'emploi a été 50 fois plus performant que Windows avec un quart de la RAM.

Pour tous ceux qui veulent affirmer que les chiffres sont erronés - pour quelque raison que ce soit - veuillez essayer et publier vos résultats.

Essayez d'utiliser jom au lieu de nmake

Obtenez-le ici: https://github.com/qt-labs/jom

Le fait est que nmake n'utilise qu'un seul de vos cœurs, jom est un clone de nmake qui utilise des processeurs multicœurs.

GNU le fait tout de suite grâce à l'option -j, cela pourrait être une raison de sa vitesse par rapport au nmake de Microsoft.

jom fonctionne en exécutant en parallèle différentes commandes make sur différents processeurs / cœurs. Essayez vous-même et sentez la différence!

Je veux ajouter juste une observation à l'aide de Gnu make et d'autres outils des outils MinGW sur Windows: ils semblent résoudre les noms d'hôte même lorsque les outils ne peuvent même pas communiquer via IP. Je suppose que cela est dû à une routine d'initialisation du runtime MinGW. L'exécution d'un proxy DNS local m'a aidé à améliorer la vitesse de compilation avec ces outils.

Avant, j'ai eu un gros mal de tête car la vitesse de construction a chuté d'un facteur 10 environ lorsque j'ai ouvert une connexion VPN en parallèle. Dans ce cas, toutes ces recherches DNS sont passées par le VPN.

Cette observation pourrait également s'appliquer à d'autres outils de construction, non seulement basés sur MinGW et elle aurait pu changer sur la dernière version de MinGW entre-temps.

J'ai récemment pu archiver un autre moyen d'accélérer la compilation d'environ 10% sur Windows en utilisant Gnu make en remplaçant mingw bash.exe par la version de win-bash

(Le win-bash n'est pas très à l'aise en ce qui concerne l'édition interactive.)