Compiler-Aktivitäten



  • Hallo,
    Wird beim Kompilieren oder beim "Programmerzeugen", also wenn ich normal die Ausgabe starte, berücksichtigt, was in einer if-Klammer steht, wenn der if-Ausdruck nicht zutrifft?

    Also,

    if ( z == 4 ){
    		[...]
    	}
    

    wenn z nicht 4 ist, wird dann überhaupt "reingeschaut"?
    Ich hab mehrere solche Abfragen drin und deren Ausdrücke sind ziemlich heftig, nun dauert es ewig...
    Ich hab MS Visual Studio 2008 und "Projektmappe erstellen F7" dauert ewig... Ich glaub beim "Verknüpfen" hängt er so lang.
    "Debugging starten F5" geht dann aber recht flott.
    btw: Wenn mein Projekt "Projekt_1" heisst, was mach ich dann mit "Projekt_1 erstellen"? Ist das dasselbe wie "F7"?



  • Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x) in das Forum Compiler- und IDE-Forum verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • background schrieb:

    Hallo,
    Wird beim Kompilieren oder beim "Programmerzeugen", also wenn ich normal die Ausgabe starte, berücksichtigt, was in einer if-Klammer steht, wenn der if-Ausdruck nicht zutrifft?

    Na sicher. Compileroptimierung kann zwar bewirken, dass bei als konstant ermittelten Bedingungen Codeteile weggeworfen werden, aber das dient der Codeverkleinerung, nicht der Verkürzung der Compilerlaufzeit. Bis zur Optimierung wurde in der Regel schon ziemlich viel von dem Quellcode analysiert.

    Ich hab mehrere solche Abfragen drin und deren Ausdrücke sind ziemlich heftig, nun dauert es ewig...
    Ich hab MS Visual Studio 2008 und "Projektmappe erstellen F7" dauert ewig... Ich glaub beim "Verknüpfen" hängt er so lang.

    Ist das MS-Deutsch für Linken? Das hat mit den ifs nichts zu tun.


  • Mod

    Normalerweise sollte der Compiler den Ausdruck in der Klammer schon verarbeiten. Optimierung kommt normalerweise erst nachdem der Compiler seine internen Datenstrukturen erzeugt hat. Wenn er dann beweisen kann, dass die if-Bedingung nie zutreffen wird, dann besteht eine gute Chance, dass sie vollständig rausfliegt. Die Frage ist natürlich, wieso sie überhaupt da ist, wenn sie niemals zutrifft.

    ...

    Irgendwie habe ich den leisen Verdacht, dass du etwas ganz anderes wissen möchtest, dich aber nur dumm ausgedrückt hast. Falls du wissen möchtest, was für Code aus so etwas erzeugt wird: So eine if-Bedinung wird auf Maschinenebene als bedingter Sprung umgesetzt. Das heißt, wenn die Bedingung nicht wahr ist, wird direkt alles übersprungen. Der Sprung an sich kostet so ungefähr einen Prozessortakt. Moderne Prozessoren verarbeiten aber viele Anweisungen gleichzeitig und lange im Voraus. Wenn sie auf einen Sprung treffen, müssen sie voraussagen, welcher Zweig wohl genommen wird. Wenn sie das falsch raten, dann müssen sie nochmal von vorne anfangen und man verliert leicht 20+ Takte. Deshalb sollten schlecht vorhersagbare (d.h. es kommt öfters was anderes raus) Sprünge in kritischen Schleifen vermieden werden. Die Schleife selbst ist auch nur eine andere Schreibweise für einen bedingten Sprung, aber sehr gut vorhersagbar, da man fast immer wieder an den Anfang springt, nur beim letzten Durchlauf nicht.

    Bei dir klingt das aber auch eher so, als hättest du deinen Compiler nicht im Griff und keine Optimierungen aktiviert.



  • @MS-Deutsch für Linken: Ja das kann sein, es ist eben eine längere Pause drin, danach kommt:

    1>Verknüpfen...
    1>LINK : C:[...].exe wurde nicht gefunden oder beim letzten inkrementellen Linkvorgang nicht erstellt; vollständiger Link wird durchgeführt.
    1>Das Manifest wird eingebettet...
    1>Das Buildprotokoll wurde unter "file://c:[...]\Debug\BuildLog.htm" gespeichert.
    1>Projekt_1 - 0 Fehler, 0 Warnung(en)
    ========== Erstellen: 1 erfolgreich, Fehler bei 0, 0 aktuell, 0 übersprungen ==========
    

    SeppJ schrieb:

    Die Frage ist natürlich, wieso sie überhaupt da ist, wenn sie niemals zutrifft.

    Niemals stimmt ja auch nicht wirklich. Ich habe gerade z's von 4 bis 10. Ganz am Ende prüf ich eben etwas ab / rechne etwas, je nach dem ob z 4, 6, 8, 10 ist.

    SeppJ schrieb:

    Bei dir klingt das aber auch eher so, als hättest du deinen Compiler nicht im Griff und keine Optimierungen aktiviert.

    Das kann natürlich auch sein. Da hab ich leider keinen Plan von...



  • Niemals stimmt ja auch nicht wirklich. Ich habe gerade z's von 4 bis 10. Ganz am Ende prüf ich eben etwas ab / rechne etwas, je nach dem ob z 4, 6, 8, 10 ist.

    Dann muss der Compiler den Code für den If-Fall doch so oder so erzeugen und linken.

    SeppJ schrieb:

    Bei dir klingt das aber auch eher so, als hättest du deinen Compiler nicht im Griff und keine Optimierungen aktiviert.

    Das kann natürlich auch sein. Da hab ich leider keinen Plan von...

    Dann wäre der beste Ansatz, das zu beheben wohl, dich mal kundig zu machen, welche Optionen es fürs Optimieren & Co. gibt. MSDN und Google hilft dir da weiter.



  • du kannst mit ein paar tricks (TMP und/oder konstanten) dafür sorgen dass ers nicht mehr anguckt beim kompilieren, aber darunter leidet meistens dann die dynamik deines programms...



  • Skym0sh0 schrieb:

    du kannst mit ein paar tricks (TMP und/oder konstanten) dafür sorgen dass ers nicht mehr anguckt beim kompilieren

    Nope. Er füttert die Funktion ja mit verschiedenen Eingaben, unter anderem mit z==4 - Selbst wenn er das für die anderen Werte wegbekommt, muss es eine Funktion geben, die den Block enthält, also wirds auch einmal durch den Compiler gejagt. Wenn er den z==4-Fall per TMP oder sonstwie getrennt übersetzen lässt, kommt nurnoch hinzu, dass der umgebende Code doppelt übersetzt werden muss - für z!=4 und z==4 jeweils separat.



  • Danke für die Hinweise und Erklärungen.
    Wenn ich an meinem Code etwas ändere und neu kompiliere, dann hab ich diese Wartezeit drin.. Wenn ich das Programm "nur" ausführe (bisher ist es nur eine textausgabe in der Konsole, später solls eine grafische Oberfläche werden), gehts ohne große Probleme.


Log in to reply