Compile Geschwindigkeit

Frank schrieb:
> gibt hier ausch einen -j Schalter

Ja

Was soll denn "Gnu Arm" sein?

gcc

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.

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.

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.

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..