Hallo, Bei der Verwendung von Yagarto (2009) hatte ich make mit J2 oder -j4 ausgeführt. Ein ganzes Projekt wurde schnell Compiliert. Bei GNU ARM habe ich keine make Files da es in WinIdea integriert ist. Gibt es irgendeine Möglichkeit Gnu Arm auf mehreren PC CPUs ausführen zu lassen und gibt hier ausch einen -j Schalter
Der gcc selbst hat keine Möglichkeit mehrere Dateien zugleich zu übersetzen. Dafür braucht es etwas wie make, was den gcc mehrfach aufruft.
Der gcc kennt noch -pipe, dann werden Compiler und Assembler parallel ausgeführt. Ob das auf Windows geht bzw was bringt, weiß ich aber nicht.
foobar schrieb: > dann werden Compiler und Assembler parallel ausgeführt Wie soll das gehen? -pipe verwendet pipes statt temporärer Dateien. Auf modernen Betriebsystemen mit ordentlichem Page Cache, spielt das aber kaum eine Rolle.
MaWin schrieb: > foobar schrieb: >> dann werden Compiler und Assembler parallel ausgeführt > > Wie soll das gehen? > > -pipe verwendet pipes statt temporärer Dateien. Auf modernen > Betriebsystemen mit ordentlichem Page Cache, spielt das aber kaum eine > Rolle. Und dessen Prozessverwaltung die Eigenheiten von Unix hat, die da ist Prozesse schnell clones zu können. Hatten wir erst vor ein paar Wochen diskutiert, ein ganz beliebtes OS ohne X im Namen kann das nicht und braucht deshalb zum Übersetzen gern mal 5..10 fache Zeit.
Bei -pipe geht es darum, Compiler und Assembler parallel zu starten und die Daten per Pipe vom ersten zum zweiten zu schicken. Es findet eine (begrenzte) parallele Verarbeitung statt. Ohne -pipe wird der Assembler erst gestartet, wenn der Compiler fertig ist - schön seriell.
foobar schrieb: > Ohne -pipe wird der Assembler > erst gestartet, wenn der Compiler fertig ist - schön seriell. Was soll denn der Assembler machen, wenn der Compiler noch am optimieren ist? Ich sehe da keine Möglichkeit zu parallelisieren. Der Vorteil von -pipe ist eher das Nichtanlegen von Dateien im Dateisystem.
> Was soll denn der Assembler machen, wenn der Compiler noch am optimieren > ist? Ich weiß nicht, wie es heute ist, aber vor einigen Jahren (als die Rechner noch langsamer waren und man das direkt sehen konnte g) kam der Assembler-Output funktionsweise raus.
foobar schrieb: >> Was soll denn der Assembler machen, wenn der Compiler noch am optimieren >> ist? > > Ich weiß nicht, wie es heute ist, aber vor einigen Jahren (als die > Rechner noch langsamer waren und man das direkt sehen konnte g) kam > der Assembler-Output funktionsweise raus. Heute hat man LTO und der Assembler erhält erst am Ende alles an Stück.
OK, der Assembler hat ehe wenig zu tun. Die 50 Files C Code machen den Löwenanteil aus. Ich werde mich mal in die make Geschichte (wieder) einarbeiten. Scheint ja die einzige Lösung zu sein meine 32 Kerne (Proll...) mal zu nutzen.
Frank schrieb: > OK, der Assembler hat ehe wenig zu tun. Die 50 Files C Code machen den > Löwenanteil aus. > Ich werde mich mal in die make Geschichte (wieder) einarbeiten. Scheint > ja die einzige Lösung zu sein meine 32 Kerne (Proll...) mal zu nutzen. Wenn ich mich übrigens Recht entsinne, brauchen aktuelle Versionen von GNU Make den Schalter "-j" nicht mehr.
Sheeva P. schrieb: > Frank schrieb: >> OK, der Assembler hat ehe wenig zu tun. Die 50 Files C Code machen den >> Löwenanteil aus. >> Ich werde mich mal in die make Geschichte (wieder) einarbeiten. Scheint >> ja die einzige Lösung zu sein meine 32 Kerne (Proll...) mal zu nutzen. > > Wenn ich mich übrigens Recht entsinne, brauchen aktuelle Versionen von > GNU Make den Schalter "-j" nicht mehr. Das wäre mir neu. Kann ich mir auch nicht vorstellen. Dafür sind viel zu viele Makefiles draussen, die im Parallelbetrieb Fehler erzeugen.
Markus F. schrieb: > Das wäre mir neu. > > Kann ich mir auch nicht vorstellen. Dafür sind viel zu viele Makefiles > draussen, die im Parallelbetrieb Fehler erzeugen. Dem ist nicht so, die letzten Wochen (mit aktuellem make) habe ich mehrere Male einen Kernel und Projekte von mir übersetzt, da war immer -j nötig/zu vermeiden. Vielleicht gibt's da eine neue Funktion, dass ein Makefile um mehrere Kerne bitten kann, oder so...
Achja, die 32 Kerne bekommst du auch nur ein paar Sekunden damit ausgelastet, einen Linux Kernel zu compilieren. Ich würde da zum Testen Firefox, Chrome oder OpenOffice compilieren. OpenOffice habe ich das erste mal auf einem 600er Celeron compiliert. Das war eine Aufgabe für den Rechner...
Markus F. schrieb: > Sheeva P. schrieb: >> Frank schrieb: >>> OK, der Assembler hat ehe wenig zu tun. Die 50 Files C Code machen den >>> Löwenanteil aus. Was ist denn das für eine Zauberei? Löwenanteil beginnt ab einigen hundert C++ Dateien mit ordentlich Template-programming... > Kann ich mir auch nicht vorstellen. Dafür sind viel zu viele Makefiles > draussen, die im Parallelbetrieb Fehler erzeugen. Oder der Schalter -j bringt kein Zeitgewinn. Es handelt sich dabei um stümperhaft geschriebene Makefiles, in denen nicht alle Abhängigkeiten unter den Dateien und Subsysteme sauber erfasst sind. Zur Verkürzung der Builddauer lohnt es sich gut & GRÜNDLICH in Make einzusteigen. Da kann man ins Staunen geraten, wieviel "Luft" in ganz vielen Projekten drin ist.
I <3 Makefiles schrieb: > Zur Verkürzung der Builddauer lohnt es sich gut & GRÜNDLICH in Make > einzusteigen. Da kann man ins Staunen geraten, wieviel "Luft" in ganz > vielen Projekten drin ist. Naja, bei dem üblichen Edit-Compile-Link-Test Zyklus spielt die Compile Dauer bei großen Programmen eigentlich keine Rolle mehr. Die Link Dauer aber sehr wohl! Und da helfen leider keine 22 Cores - da braucht man GHz! Ein großer L3 Cache kann auch etwas helfen..
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.