Wie kann ich Windows so schnell wie Linux zum Kompilieren von C ++ bringen?


142

Ich weiß, dass dies nicht so sehr eine Programmierfrage ist, aber es ist relevant.

Ich arbeite an einem ziemlich großen plattformübergreifenden Projekt . Unter Windows verwende ich VC ++ 2008. Unter Linux verwende ich gcc. Das Projekt enthält ca. 40.000 Dateien. Windows ist beim Kompilieren und Verknüpfen desselben Projekts 10x bis 40x langsamer als Linux. Wie kann ich das beheben?

Eine einzelne Änderung inkrementell Build 20 Sekunden unter Linux und> 3 Minuten unter Windows. Warum? Ich kann sogar den 'Gold'-Linker unter Linux installieren und diese Zeit auf 7 Sekunden reduzieren.

Ebenso ist Git unter Linux 10x bis 40x schneller als unter Windows.

Im Git-Fall ist es möglich, dass Git Windows nicht optimal nutzt, sondern VC ++? Man könnte meinen, Microsoft möchte seine eigenen Entwickler so produktiv wie möglich machen, und eine schnellere Kompilierung würde einen großen Beitrag dazu leisten. Vielleicht versuchen sie, Entwickler zu C # zu ermutigen?

Suchen Sie als einfachen Test einen Ordner mit vielen Unterordnern und führen Sie einen einfachen aus

dir /s > c:\list.txt

unter Windows. Tun Sie es zweimal und legen Sie den zweiten Lauf fest, damit er aus dem Cache ausgeführt wird. Kopieren Sie die Dateien nach Linux und führen Sie die entsprechenden 2 Läufe und den zweiten Lauf aus.

ls -R > /tmp/list.txt

Ich habe 2 Workstations mit genau den gleichen Spezifikationen. HP Z600s mit 12 Gigabyte RAM, 8 Kerne bei 3,0 GHz. In einem Ordner mit ~ 400.000 Dateien dauert Windows 40 Sekunden, Linux <1 Sekunde.

Gibt es eine Registrierungseinstellung, die ich festlegen kann, um Windows zu beschleunigen? Was gibt?


Einige leicht relevante Links, die für die Kompilierungszeiten relevant sind, nicht unbedingt i / o.


5
Ich weiß nicht warum, aber dies ist ein bekannter Unterschied in den Leistungsmerkmalen von Windows und Linux. Linux ist viel besser als Windows im Umgang mit vielen Dateien in einem einzigen Verzeichnis, möglicherweise ist es nur NTFS vs ext4 / was auch immer? Könnte auch sein, dass das Windows-Äquivalent zum Dentry-Cache von Linux einfach nicht so gut ist.
Spudd86

73
Warum war das geschlossen? "Nicht konstruktiv sein" ??! Ich finde es ziemlich relevant für Entwickler.
Nils

3
Diese Frage enthält Fakten und kann durch eine beliebige Anzahl von Fakten, Referenzen usw. gestützt werden. Nur zu denken, dass ein Titel kontrovers erscheint, sollte uns nicht davon abhalten, ein langjähriges, aber nicht genug besprochenes Thema zu diskutieren. Da ich selbst ein langjähriger Windows-Benutzer bin, möchte ich diese Frage stellen und hoffentlich jederzeit produktive Antworten erhalten. Bitte öffnen Sie die Frage erneut, es sei denn, Sie können tatsächlich nachweisen, dass die Frage von Natur aus argumentativ ist und nicht durch Fakten gestützt wird. Ansonsten bist du nur ein Moderatorobot.
Halil Özgür

2
@ HalilÖzgür: OK, Ihr Kommentar veranlasste mich bei der Revision der Geschichte zu betrachten - der ursprüngliche Frage Titel wurde so etwas zu fragen. Das kann sehr wohl der Grund gewesen sein (ich nicht zu schließen gestimmt haben), denn es war ein Beitrag von jemand deutlich von dem ursprünglichen Titel beleidigt und begann tobt, die dann gelöscht wurde, auf diese Frage Schließung führt. Der Titel wurde seitdem bearbeitet, also denke ich, wir können loslegen. Wiedereröffnet. Denken Sie daran, dass Sie immer noch versuchen sollten, die Frage nicht zu diskutieren ... da das OP nach Antworten sucht, Antworten gibt, sonst nichts.
BoltClock

2
Es wäre großartig, jemanden wie @ raymond-chen mit einigen Einsichten zu sehen - wenn die Frage technisch bleibt und klar genug Daten / Fakten bietet, um das Problem zu reproduzieren.
Benjamin Podszun

Antworten:


32

Wenn kein Hardcore-Hacker für Windows-Systeme hinzukommt, werden Sie nicht mehr als parteipolitische Kommentare (was ich nicht tun werde) und Spekulationen (was ich versuchen werde) erhalten.

  1. Dateisystem - Sie sollten dieselben Vorgänge (einschließlich der dir) auf demselben Dateisystem ausführen . Ich kam in diese , die einige Dateisysteme für verschiedene Parameter Benchmarks.

  2. Caching. Ich habe einmal versucht, eine Kompilierung unter Linux auf einer RAM-Disk auszuführen, und festgestellt, dass sie langsamer ist als die Ausführung auf einer Festplatte, da der Kernel das Caching übernimmt. Dies ist ein solides Verkaufsargument für Linux und möglicherweise der Grund, warum die Leistung so unterschiedlich ist.

  3. Schlechte Abhängigkeitsspezifikationen unter Windows. Möglicherweise sind die Chromabhängigkeitsspezifikationen für Windows nicht so korrekt wie für Linux. Dies kann zu unnötigen Kompilierungen führen, wenn Sie eine kleine Änderung vornehmen. Möglicherweise können Sie dies mit derselben Compiler-Toolchain unter Windows überprüfen.


Könnten Sie etwas näher auf # 2 eingehen? Es ist ziemlich überraschend - liegt es daran, dass der Kernel keine Daten auf der RAM-Disk zwischenspeichert oder so?
user541686

2
Wenn Sie einen Teil eines Speichers als Ramdisk zuweisen, steht er dem Kernel nicht zum Zwischenspeichern oder zur Verwendung für andere Zwecke zur Verfügung. Tatsächlich ringen Sie seine Hand und zwingen ihn, weniger Speicher für seine eigenen Algorithmen zu verwenden. Mein Wissen ist empirisch. Ich habe an Leistung verloren, als ich eine RAM-Disk für Kompilierungen verwendet habe.
Noufal Ibrahim

1
"Wenn [ein Experte für ein bestimmtes Thema] nicht vorbeikommt, werden Sie nicht mehr als parteipolitische Kommentare ... und Spekulationen erhalten": Wie unterscheidet sich das von jeder anderen Frage?
Dolph

1
Dieser ist dank des Win vs. Lin-Themas eher ein Fanboy-Magnet. Auch ist die Frage im Gegensatz zu direkten, die nur nach Befehlen oder Verwendungsmethoden fragen, eher nuanciert.
Noufal Ibrahim

Der Link in # 1 ist nicht mehr aktiv.
Alkasm

28

Ein paar Ideen:

  1. Deaktivieren Sie 8.3 Namen. Dies kann bei Laufwerken mit einer großen Anzahl von Dateien und einer relativ kleinen Anzahl von Ordnern ein großer Faktor sein:fsutil behavior set disable8dot3 1
  2. Verwenden Sie mehr Ordner. Nach meiner Erfahrung verlangsamt sich NTFS mit mehr als 1000 Dateien pro Ordner.
  3. Aktivieren Sie parallele Builds mit MSBuild. Fügen Sie einfach den Schalter "/ m" hinzu, und es wird automatisch eine Kopie von MSBuild pro CPU-Kern gestartet.
  4. Legen Sie Ihre Dateien auf eine SSD - hilft enorm bei zufälligen E / A.
  5. Wenn Ihre durchschnittliche Dateigröße viel größer als 4 KB ist, sollten Sie das Dateisystem mit einer größeren Clustergröße neu erstellen, die in etwa Ihrer durchschnittlichen Dateigröße entspricht.
  6. Stellen Sie sicher, dass die Dateien defragmentiert wurden. Fragmentierte Dateien verursachen viele Festplattensuchen, was den Durchsatz um den Faktor 40+ kosten kann. Verwenden Sie das Dienstprogramm "contig" von sysinternals oder den integrierten Windows-Defragmentierer.
  7. Wenn Ihre durchschnittliche Dateigröße klein ist und die Partition, auf der Sie sich befinden, relativ voll ist, wird möglicherweise eine fragmentierte MFT ausgeführt, was die Leistung beeinträchtigt. Dateien, die kleiner als 1 KB sind, werden direkt in der MFT gespeichert. Das oben erwähnte Dienstprogramm "contig" kann helfen, oder Sie müssen möglicherweise die MFT-Größe erhöhen. Der folgende Befehl verdoppelt ihn auf 25% des Volumens: fsutil behavior set mftzone 2Ändern Sie die letzte Zahl auf 3 oder 4, um die Größe um zusätzliche 12,5% -Schritte zu erhöhen. Starten Sie nach dem Ausführen des Befehls neu und erstellen Sie das Dateisystem.
  8. Letzte Zugriffszeit deaktivieren: fsutil behavior set disablelastaccess 1
  9. Deaktivieren Sie den Indizierungsdienst
  10. Deaktivieren Sie Ihre Antiviren- und Antispyware-Software oder legen Sie zumindest fest, dass die entsprechenden Ordner ignoriert werden.
  11. Legen Sie Ihre Dateien auf einem anderen physischen Laufwerk als das Betriebssystem und die Auslagerungsdatei ab. Durch die Verwendung eines separaten physischen Laufwerks kann Windows parallele E / A für beide Laufwerke verwenden.
  12. Schauen Sie sich Ihre Compiler-Flags an. Der Windows C ++ - Compiler bietet eine Vielzahl von Optionen. Stellen Sie sicher, dass Sie nur diejenigen verwenden, die Sie wirklich benötigen.
  13. Versuchen Sie, die vom Betriebssystem für Paged-Pool-Puffer verwendete Speichermenge zu erhöhen (stellen Sie sicher, dass Sie zuerst über genügend RAM verfügen): fsutil behavior set memoryusage 2
  14. Überprüfen Sie das Windows-Fehlerprotokoll, um sicherzustellen, dass keine gelegentlichen Festplattenfehler auftreten.
  15. Sehen Sie sich die Leistungsindikatoren für physische Festplatten an, um festzustellen, wie ausgelastet Ihre Festplatten sind. Hohe Warteschlangenlängen oder lange Zeiten pro Übertragung sind schlechte Anzeichen.
  16. Die ersten 30% der Festplattenpartitionen sind in Bezug auf die Rohübertragungszeit viel schneller als der Rest der Festplatte. Engere Partitionen tragen auch dazu bei, die Suchzeiten zu minimieren.
  17. Verwenden Sie RAID? In diesem Fall müssen Sie möglicherweise die Auswahl des RAID-Typs optimieren (RAID-5 ist schlecht für schreibintensive Vorgänge wie das Kompilieren).
  18. Deaktivieren Sie alle Dienste, die Sie nicht benötigen
  19. Ordner defragmentieren: Kopieren Sie alle Dateien auf ein anderes Laufwerk (nur die Dateien), löschen Sie die Originaldateien, kopieren Sie alle Ordner auf ein anderes Laufwerk (nur die leeren Ordner), löschen Sie dann die Originalordner, defragmentieren Sie das Originallaufwerk und kopieren Sie zuerst die Ordnerstruktur zurück Kopieren Sie dann die Dateien. Wenn Windows große Ordner einzeln erstellt, werden die Ordner fragmentiert und langsam. ("contig" soll auch hier helfen)
  20. Wenn Sie an E / A gebunden sind und CPU-Zyklen sparen müssen, aktivieren Sie die Festplattenkomprimierung. Es kann einige erhebliche Beschleunigungen für stark komprimierbare Dateien (wie Quellcode) bieten, wobei die CPU einige Kosten verursacht.

1
Selbst wenn Sie all diese Dinge tun würden, würden Sie der Linux-Leistung nicht nahe kommen. Probieren Sie den folgenden Test aus und veröffentlichen Sie Ihr Timing, wenn Sie nicht einverstanden sind.
b7kich

6
Wir brauchen einen besseren Maßstab. Das Messen der Zeit, die zum Auflisten eines Ordners benötigt wird, ist IMO nicht sehr nützlich. NTFS ist für Suchzeiten einzelner Dateien mit einer btree-Struktur optimiert. Unter Linux (zuletzt habe ich nachgesehen) kann eine App einen gesamten Ordner mit einem einzigen Systemaufruf lesen und die resultierende Struktur vollständig im Benutzercode durchlaufen. Windows erfordert für jede Datei einen separaten Systemaufruf. In jedem Fall sollten Compiler nicht den gesamten Ordner lesen müssen ...
RickNZ

3
Dann beschreiben Sie genau das Problem. Die Auswahl eines anderen Benchmarks löst das Problem nicht - Sie schauen nur weg.
b7kich

2
Die Frage war nach der Optimierung der Kompilierungszeiten. Ordneraufzählungszeiten dominieren die Kompilierungszeiten unter Windows nicht, selbst bei Zehntausenden von Dateien in einem Ordner.
RickNZ

1
Nachdem ich einige der oben vorgeschlagenen Änderungen vorgenommen habe, dauert der zweite Durchlauf von "ls -R" für den Chrombaum für mich 4,3 Sekunden (gegenüber 40 Sekunden im OP). "dir / s" dauert ungefähr eine Sekunde. Das Wechseln zu einer SSD hat nicht nur für die Aufzählung geholfen, aber ich vermute, dass es beim Kompilieren helfen wird.
RickNZ

25

NTFS spart jedes Mal Dateizugriffszeit. Sie können versuchen, es zu deaktivieren: "fsutil behaviour set disablelastaccess 1" (Neustart)


6
Tests, die 4 Sekunden weniger als die vorherigen 36 waren. Immer noch abscheulich im Vergleich zu 0,6 Sekunden auf meiner Linux-VM
b7kich

21

Das Problem mit Visual C ++ ist, soweit ich das beurteilen kann, dass es für das Compilerteam keine Priorität ist, dieses Szenario zu optimieren. Ihre Lösung besteht darin, dass Sie die vorkompilierte Header-Funktion verwenden. Dies haben Windows-spezifische Projekte getan. Es ist nicht tragbar, aber es funktioniert.

Darüber hinaus verfügen Sie unter Windows normalerweise über Virenscanner sowie Tools zur Systemwiederherstellung und -suche, die Ihre Erstellungszeiten vollständig beeinträchtigen können, wenn sie Ihren Buid-Ordner für Sie überwachen. Windows 7 Resouce Monitor kann Ihnen helfen, es zu erkennen. Ich habe hier eine Antwort mit einigen weiteren Tipps zur Optimierung der vc ++ - Erstellungszeiten, wenn Sie wirklich interessiert sind.


17

Ich persönlich habe festgestellt, dass das Ausführen einer virtuellen Windows-Maschine unter Linux es geschafft hat, einen Großteil der E / A-Langsamkeit in Windows zu beseitigen, wahrscheinlich weil die Linux-VM viel Caching durchführte, was Windows selbst nicht war.

Auf diese Weise konnte ich die Kompilierungszeiten eines großen (250Kloc) C ++ - Projekts, an dem ich arbeitete, von etwa 15 Minuten auf etwa 6 Minuten beschleunigen.


Ernsthaft? Du meinst, ich sollte es versuchen, eine VM als Entwicklungsmaschine zu verwenden? Klingt seltsam ... welche VM verwenden Sie?
Martin Booka Weser

8
Ich habe das obige Szenario mit einer Ubuntu 11.04-VM getestet, die auf meiner Windows 7-Workstation ausgeführt wird. 0,6 Sek. Für die Linux-VM, 36 Sek. Für meine Windows-Workstation
b7kich

2
Wenn Sie virtualbox verwenden und ein freigegebenes Laufwerk einrichten, können Sie Ihre Kompilierungen im Wesentlichen kostenlos beschleunigen.
Orlp

Der Wortlaut hier ist sehr verwirrend, aber ich gehe davon aus, dass es sich um eine von Windows gehostete VM unter Linux handelt, nicht um eine unter Linux gehostete VM, was interessant ist Eine unter Linux gehostete VM zum Kompilieren führte zu höheren Geschwindigkeiten als das native Ausführen von Windows - und das wäre wirklich etwas gewesen.
underscore_d

@underscore_d, ich habe etwas gesehen , bei dem ein Windows in einer VM viel schneller läuft als auf echter Hardware. Wahrscheinlich, weil Linux Windows mitgeteilt hat, dass es auf einer echten Festplatte ausgeführt wird, während Linux tatsächlich hinter den Kulissen aggressives Caching durchgeführt hat. Die Installation von Windows in der virtuellen Maschine ging zum Beispiel ebenfalls rasant schnell. Dies war in den XP-Tagen, aber ich wäre überrascht, wenn es heute einen großen Unterschied gäbe.
Prof. Falken

17

Die Schwierigkeit dabei ist auf die Tatsache zurückzuführen, dass C ++ dazu neigt, sich selbst und den Kompilierungsprozess auf viele kleine, individuelle Dateien zu verteilen. Das ist etwas, was Linux gut kann und Windows nicht. Wenn Sie einen wirklich schnellen C ++ - Compiler für Windows erstellen möchten, versuchen Sie, alles im RAM zu belassen und das Dateisystem so wenig wie möglich zu berühren.

Auf diese Weise können Sie auch eine schnellere Linux C ++ - Kompilierungskette erstellen. Unter Linux ist dies jedoch weniger wichtig, da das Dateisystem bereits einen Großteil dieser Optimierung für Sie vornimmt.

Der Grund dafür liegt in der Unix-Kultur: In der Vergangenheit hatte die Leistung von Dateisystemen in der Unix-Welt eine viel höhere Priorität als in Windows. Um nicht zu sagen, dass es unter Windows keine Priorität hatte, nur dass es unter Unix eine höhere Priorität hatte.

  1. Zugriff auf den Quellcode.

    Sie können nicht ändern, was Sie nicht kontrollieren können. Der fehlende Zugriff auf Windows NTFS-Quellcode bedeutet, dass die meisten Anstrengungen zur Verbesserung der Leistung durch Hardwareverbesserungen unternommen wurden. Wenn die Leistung langsam ist, können Sie das Problem umgehen, indem Sie die Hardware verbessern: den Bus, das Speichermedium usw. Sie können nur so viel tun, wenn Sie das Problem umgehen und nicht beheben müssen.

    Der Zugriff auf Unix-Quellcode (noch vor Open Source) war weiter verbreitet. Wenn Sie also die Leistung verbessern möchten, sollten Sie dies zuerst in Software (billiger und einfacher) und dann in Hardware behandeln.

    Infolgedessen haben viele Menschen auf der Welt promoviert, indem sie das Unix-Dateisystem studiert und neue Wege gefunden haben, um die Leistung zu verbessern.

  2. Unix tendiert zu vielen kleinen Dateien. Windows tendiert zu wenigen (oder einer einzelnen) großen Datei.

    Unix-Anwendungen verarbeiten in der Regel viele kleine Dateien. Stellen Sie sich eine Softwareentwicklungsumgebung vor: viele kleine Quelldateien, jede mit ihrem eigenen Zweck. In der letzten Phase (Verknüpfung) wird zwar eine große Datei erstellt, dies ist jedoch ein kleiner Prozentsatz.

    Infolgedessen verfügt Unix über hochoptimierte Systemaufrufe zum Öffnen und Schließen von Dateien, Scannen von Verzeichnissen usw. Die Geschichte der Unix-Forschungsarbeiten umfasst Jahrzehnte von Dateisystemoptimierungen, bei denen viel über die Verbesserung des Verzeichniszugriffs (Lookups und vollständige Verzeichnisscans), das erstmalige Öffnen von Dateien usw. nachgedacht wurde.

    Windows-Anwendungen neigen dazu, eine große Datei zu öffnen, sie lange offen zu halten und sie dann zu schließen. Denken Sie an MS-Word. msword.exe (oder was auch immer) öffnet die Datei einmal und hängt sie stundenlang an, aktualisiert interne Blöcke und so weiter. Der Wert der Optimierung des Öffnens der Datei wäre Zeitverschwendung.

    In der Geschichte des Windows-Benchmarking und der Windows-Optimierung ging es darum, wie schnell man lange Dateien lesen oder schreiben kann. Das wird optimiert.

    Leider hat die Softwareentwicklung in Richtung der ersten Situation tendiert. Heck, das beste Textverarbeitungssystem für Unix (TeX / LaTeX) empfiehlt Ihnen, jedes Kapitel in eine andere Datei zu legen und alle zusammen einzuschließen.

  3. Unix konzentriert sich auf hohe Leistung; Windows konzentriert sich auf die Benutzererfahrung

    Unix wurde im Serverraum gestartet: keine Benutzeroberfläche. Das einzige, was Benutzer sehen, ist Geschwindigkeit. Geschwindigkeit hat daher Priorität.

    Windows wurde auf dem Desktop gestartet: Benutzer kümmern sich nur um das, was sie sehen, und sie sehen die Benutzeroberfläche. Daher wird mehr Energie für die Verbesserung der Benutzeroberfläche aufgewendet als für die Leistung.

  4. Das Windows-Ökosystem hängt von der geplanten Veralterung ab. Warum Software optimieren, wenn neue Hardware nur ein oder zwei Jahre entfernt ist?

    Ich glaube nicht an Verschwörungstheorien, aber wenn ich das tun würde, würde ich darauf hinweisen, dass es in der Windows-Kultur weniger Anreize gibt, die Leistung zu verbessern. Windows-Geschäftsmodelle hängen davon ab, dass Menschen neue Maschinen wie ein Uhrwerk kaufen. (Aus diesem Grund ist der Aktienkurs von Tausenden von Unternehmen betroffen, wenn MS ein Betriebssystem verspätet ausliefert oder wenn Intel ein Veröffentlichungsdatum für Chips verpasst.) Dies bedeutet, dass es einen Anreiz gibt, Leistungsprobleme zu lösen, indem die Leute aufgefordert werden, neue Hardware zu kaufen. nicht durch die Verbesserung des eigentlichen Problems: langsame Betriebssysteme. Unix kommt aus dem akademischen Bereich, wo das Budget knapp ist und Sie promovieren können, indem Sie eine neue Methode erfinden, um Dateisysteme schneller zu machen. Selten erhält jemand in der Wissenschaft Punkte für die Lösung eines Problems durch Erteilung einer Bestellung.

    Da Unix Open Source ist (auch wenn dies nicht der Fall war, hatte jeder Zugriff auf die Quelle), kann jeder gelangweilte Doktorand den Code lesen und berühmt werden, indem er ihn verbessert. Dies ist in Windows nicht der Fall (MS verfügt über ein Programm, mit dem Akademiker auf Windows-Quellcode zugreifen können, das nur selten genutzt wird). Schauen Sie sich diese Auswahl von Unix-bezogenen Performance-Papieren an: http://www.eecs.harvard.edu/margo/papers/ oder schauen Sie sich die Geschichte der Papiere von Osterhaus, Henry Spencer oder anderen an. Heck, eine der größten (und erfreulichsten) Debatten in der Unix-Geschichte war das Hin und Her zwischen Osterhaus und Selzer http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal. html In der Windows-Welt sieht man so etwas nicht. Möglicherweise sehen Sie Anbieter, die sich gegenseitig verbessern, aber das scheint in letzter Zeit viel seltener zu sein, da die Innovation anscheinend alle auf der Ebene der Standardkörper liegt.

So sehe ich das.

Update: Wenn Sie sich die neuen Compilerketten ansehen, die von Microsoft kommen, werden Sie sehr optimistisch sein, da vieles, was sie tun, es einfacher macht, die gesamte Toolchain im RAM zu halten und weniger Arbeit zu wiederholen. Sehr beeindruckendes Zeug.


6
Zu sagen, dass der Grund "kulturell, nicht technisch" ist, beantwortet die Frage nicht wirklich. Offensichtlich gibt es einen oder mehrere technische Gründe, warum bestimmte Vorgänge unter Windows langsamer sind als unter Linux. Jetzt können die kulturellen Probleme erklären, warum Menschen technische Entscheidungen getroffen haben, die sie getroffen haben; Dies ist jedoch eine technische Q & A-Site. Die Antworten sollten die technischen Gründe abdecken, warum ein System langsamer als das andere ist (und was getan werden kann, um die Situation zu verbessern), und nicht unbeweisbare Vermutungen über Kultur.
Brian Campbell

Dies scheint nicht viele technische Informationen zu haben. Meistens finanziell. Ich denke, der einzige Weg, um echte technische Informationen zu erhalten, besteht darin, die Unterschiede zwischen den beiden Compilern, Build-Systemen usw. usw. zu betrachten
surfasb

Windows-Anwendungen neigen dazu, eine große Datei zu öffnen und sie lange offen zu halten - viele UNIX-Apps tun dies. Server, meine Emacs usw.
Noufal Ibrahim

Ich glaube nicht, dass Emacs Dateien lange offen hält, egal ob sie groß oder klein sind. Es schreibt sicherlich nicht in die Mitte der Datei und aktualisiert sie wie eine Datenbank.
TomOnTime

… Und Server machen das auch nicht. Ihre Funktionen auf * nix-Systemen sind normalerweise in viele kleine Module unterteilt, wobei der Serverkern im Wesentlichen eine leere Hülle ist.
Spektren

7

Inkrementelle Verknüpfung

Wenn die VC 2008-Lösung als mehrere Projekte mit .lib-Ausgaben eingerichtet ist, müssen Sie "Use Library Dependency Inputs" festlegen. Dadurch wird der Linker direkt mit den OBJ-Dateien und nicht mit der LIB verknüpft. (Und macht es tatsächlich inkrementell verknüpfen.)

Durchlaufleistung des Verzeichnisses

Es ist etwas unfair, das Crawlen von Verzeichnissen auf dem ursprünglichen Computer mit dem Crawlen eines neu erstellten Verzeichnisses mit denselben Dateien auf einem anderen Computer zu vergleichen. Wenn Sie einen gleichwertigen Test wünschen, sollten Sie wahrscheinlich eine weitere Kopie des Verzeichnisses auf dem Quellcomputer erstellen. (Es kann immer noch langsam sein, aber das kann auf eine Reihe von Faktoren zurückzuführen sein: Festplattenfragmentierung, kurze Dateinamen, Hintergrunddienste usw.) Obwohl ich denke, dass die Perf-Probleme dir /smehr mit dem Schreiben der Ausgabe als mit dem Messen der tatsächlichen Datei zu tun haben Durchquerungsleistung. Auch dir /s /b > nulist auf meinem Computer mit einem riesigen Verzeichnis langsam.


6

Ich bin mir ziemlich sicher, dass es mit dem Dateisystem zusammenhängt. Ich arbeite an einem plattformübergreifenden Projekt für Linux und Windows, bei dem der gesamte Code gemeinsam ist, außer wenn plattformabhängiger Code unbedingt erforderlich ist. Wir verwenden Mercurial, nicht Git, daher gilt die "Linuxness" von Git nicht. Das Abrufen von Änderungen aus dem zentralen Repository dauert unter Windows im Vergleich zu Linux ewig, aber ich muss sagen, dass unsere Windows 7-Computer viel besser abschneiden als die Windows XP-Computer. Das Kompilieren des Codes danach ist in VS 2008 noch schlimmer. Es ist nicht nur hg; CMake läuft auch unter Windows viel langsamer, und beide Tools verwenden das Dateisystem mehr als alles andere.

Das Problem ist so schlimm, dass die meisten unserer Entwickler, die in einer Windows-Umgebung arbeiten, sich nicht einmal mehr um inkrementelle Builds kümmern - sie finden, dass das Erstellen eines Unity- Builds schneller ist.

Übrigens, wenn Sie die Kompilierungsgeschwindigkeit in Windows drastisch verringern möchten, würde ich den oben genannten Unity-Build vorschlagen. Die korrekte Implementierung im Build-System ist mühsam (ich habe es für unser Team in CMake getan), aber wenn dies einmal erledigt ist, werden die Dinge für unsere Continuous Integration Server automatisch beschleunigt. Abhängig davon, wie viele Binärdateien Ihr Build-System ausspuckt, können Sie eine Verbesserung um 1 bis 2 Größenordnungen erzielen. Ihr Kilometerstand kann variieren. In unserem Fall hat es meiner Meinung nach die Linux-Builds um das Dreifache und die Windows-Builds um den Faktor 10 beschleunigt, aber wir haben viele gemeinsam genutzte Bibliotheken und ausführbare Dateien (was die Vorteile eines Unity-Builds verringert).


5

Wie bauen Sie Ihr großes plattformübergreifendes Projekt auf? Wenn Sie gängige Makefiles für Linux und Windows verwenden, können Sie die Windows-Leistung leicht um den Faktor 10 beeinträchtigen, wenn die Makefiles unter Windows nicht so schnell sind.

Ich habe gerade einige Makefiles eines plattformübergreifenden Projekts mit allgemeinen (GNU) Makefiles für Linux und Windows repariert. Make startet einen sh.exeProzess für jede Zeile eines Rezepts, der den Leistungsunterschied zwischen Windows und Linux verursacht!

Nach Angaben der GNU Dokumentation erstellen

.ONESHELL:

sollte das Problem lösen, aber diese Funktion wird (derzeit) für Windows make nicht unterstützt. Das Umschreiben der Rezepte in einzelne logische Zeilen (z. B. durch Hinzufügen von; \ oder \ am Ende der aktuellen Editorzeilen) hat also sehr gut funktioniert!


4

IMHO dreht sich alles um die Leistung der Festplatten-E / A. Die Größenordnung legt nahe, dass viele Vorgänge unter Windows auf die Festplatte übertragen werden, während sie unter Linux im Speicher ausgeführt werden, dh Linux wird besser zwischengespeichert. Unter Windows können Sie Ihre Dateien am besten auf eine schnelle Festplatte, einen Server oder ein Dateisystem verschieben. Erwägen Sie den Kauf eines Solid State Drive oder das Verschieben Ihrer Dateien auf eine Ramdisk oder einen schnellen NFS-Server.

Ich habe die Verzeichnisdurchlauftests durchgeführt und die Ergebnisse liegen sehr nahe an den angegebenen Kompilierungszeiten, was darauf hindeutet, dass dies überhaupt nichts mit CPU-Verarbeitungszeiten oder Compiler / Linker-Algorithmen zu tun hat.

Gemessene Zeiten wie oben vorgeschlagen beim Durchlaufen des Chromverzeichnisbaums:

  • Windows Home Premium 7 (8 GB RAM) unter NTFS: 32 Sekunden
  • Ubuntu 11.04 Linux (2 GB RAM) unter NTFS: 10 Sekunden
  • Ubuntu 11.04 Linux (2 GB RAM) auf ext4: 0,6 Sekunden

Für die Tests habe ich die Chromquellen gezogen (beide unter Win / Linux)

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

Um die Zeit zu messen, die ich lief

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

Ich habe die Zugriffszeitstempel und meinen Virenscanner deaktiviert und die Cache-Manager-Einstellungen unter Windows (> 2 GB RAM) erhöht - alles ohne merkliche Verbesserungen. Tatsache ist, dass Linux mit einem Viertel des Arbeitsspeichers 50-mal besser abschneidet als Windows.

Für alle, die behaupten wollen, dass die Zahlen - aus welchen Gründen auch immer - falsch sind, probieren Sie es bitte aus und veröffentlichen Sie Ihre Ergebnisse.


1
Nachdem ich einige der in meiner Antwort für Windows beschriebenen Optimierungen vorgenommen hatte, dauerte das Ausführen des obigen "ls -lR" -Tests auf dem Chrombaum 19,4 Sekunden. Wenn ich stattdessen "ls -UR" verwende (das keine Dateistatistiken erhält), sinkt die Zeit auf 4,3 Sekunden. Das Verschieben des Baums auf eine SSD hat nichts beschleunigt, da die Dateidaten nach dem ersten Ausführen vom Betriebssystem zwischengespeichert werden.
RickNZ

Danke für das Teilen! Trotz einer soliden Verbesserung um Faktor 10 im Vergleich zum Windows 7-Out-of-the-Box-Szenario ist dies immer noch ein Faktor 10, der schlechter ist als Linux / ext4.
b7kich

Ich dachte, der Sinn des OP sei es, die Windows-Leistung zu verbessern, oder? Wie oben erwähnt, läuft "dir / s" in ungefähr einer Sekunde.
RickNZ

3

Versuchen Sie es mit jom anstelle von nmake

Erhalten Sie es hier: https://github.com/qt-labs/jom

Tatsache ist, dass nmake nur einen Ihrer Kerne verwendet. Jom ist ein Klon von nmake, der Multicore-Prozessoren verwendet.

GNU macht dies dank der Option -j sofort möglich. Dies könnte ein Grund für die Geschwindigkeit im Vergleich zu Microsoft nmake sein.

jom arbeitet mit der parallelen Ausführung verschiedener make-Befehle auf verschiedenen Prozessoren / Kernen. Probieren Sie es aus und spüren Sie den Unterschied!


1

Ich möchte nur eine Beobachtung mit Gnu make und anderen Tools von MinGW-Tools unter Windows hinzufügen: Sie scheinen Hostnamen aufzulösen, selbst wenn die Tools nicht einmal über IP kommunizieren können. Ich würde vermuten, dass dies durch eine Initialisierungsroutine der MinGW-Laufzeit verursacht wird. Das Ausführen eines lokalen DNS-Proxys hat mir geholfen, die Kompilierungsgeschwindigkeit mit diesen Tools zu verbessern.

Vorher hatte ich große Kopfschmerzen, weil die Build-Geschwindigkeit um den Faktor 10 abnahm, als ich parallel eine VPN-Verbindung eröffnete. In diesem Fall wurden alle diese DNS-Suchvorgänge über das VPN durchgeführt.

Diese Beobachtung könnte auch für andere Build-Tools gelten, die nicht nur auf MinGW basieren, und sie könnte sich inzwischen gegenüber der neuesten MinGW-Version geändert haben.


0

Ich konnte kürzlich eine andere Möglichkeit archivieren, um die Kompilierung unter Windows mit Gnu make um etwa 10% zu beschleunigen, indem ich die Datei mingw bash.exe durch die Version von win-bash ersetzte

(Die Win-Bash ist in Bezug auf die interaktive Bearbeitung nicht sehr komfortabel.)

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.