3. Inline-Optimierungen

Inline-Optimierungen

  • N

    Anlässlich eines aktuellen Threades und der Diskussion, die schon oft aufgekommen ist, möchte ich mal Klarheit in diesem Thema.

    Inwiefern kann der Compiler gut abschätzen, ob sich das Inlining einer Funktion lohnt? Zählt er Assemblerbefehle innerhalb der Funktion und Anzahl Aufrufe und wägt diese dann ab?

    Wie verhält es sich bei Funktionen, die als inline fest im Design verankert sind, indem sie innerhalb von Headerdateien definiert sind? Oder im Gegensatz kurze Get/Set-Methoden, die in CPP-Dateien implementiert sind? Kann der Linker da beliebig manipulieren?

    Und ist das Schlüsselwort inline demzufolge wirklich absolut sinnlos bei modernen Compilern?

    0
  • U

    ein interessanter artikel über den MSVC ist hier:

    http://msdn.microsoft.com/en-us/library/aa289170(VS.71).aspx

    hab ihn aber weitestgehend nur überflogen - falls du nach dem Lesen schlauer bist, kannste ja ma was dazu schreiben, wenn du Lust hast ^^

    Zur Frage, ob inline sinnlos ist:

    Use the inline threshold switch with great caution.

    Nur leider ergibt der Satz für mich nicht so recht Sinn - hab keine passende Übersetzung für treshold gefunden 😕
    Und deshalb und weil ich nicht alles gelesen habe, weiß ich also nicht, ob damit das keyword gemeint ist, oder irgend ne Option bzw. nen Schalter...

    Inwiefern kann der Compiler gut abschätzen, ob sich das Inlining einer Funktion lohnt?

    Das hängt mit Sicherheit schon mal davon ab, was man bei Optimization angibt, beim MSVC gibts da min. Code-Größe, max. Speed und "Full optimization" - kein Plan, was er bei full macht - er wird wo einfach nicht mehr alles inlinen - was er bei max. Speed aber bestimmt macht ^^

    bb

    0
  • S

    unskilled schrieb:

    Inwiefern kann der Compiler gut abschätzen, ob sich das Inlining einer Funktion lohnt?

    Das hängt mit Sicherheit schon mal davon ab, was man bei Optimization angibt, beim MSVC gibts da min. Code-Größe, max. Speed und "Full optimization" - kein Plan, was er bei full macht - er wird wo einfach nicht mehr alles inlinen - was er bei max. Speed aber bestimmt macht ^^

    Inlining kann den Code langsamer machen.

    Es ist eine Gratwanderung. Ein Funktionsaufruf kostet eine Menge Code: du musst die register sichern, werte auf den stack pushen und nachher wieder poppen und die register wieder herstellen.

    aber inlining produziert mehr code. da ja die ganze funktion hier eingefuegt wird, statt nur der call der funktion. das kann nun mit sich bringen dass wir nicht mehr in den cache passen oder die branch prediction nicht komplett greifen kann. mehr code heisst ja auch: mehr daten die transferiert muessen.

    alles inline machen ist also defintiv schlecht.

    der compiler tut jetzt einfach gewisse abschaetzungen vornehmen und je nachdem eben sich fuer inline entscheiden oder dagegen. uU wird er eine funktion nur manchmal inlinen und manchmal nicht...

    Das inline keyword dagegen gibt es ja nur wegen der ODR und hat keine performance Wirkung. Je nachdem wie gut der Compiler ist - der VC++ kann zB whole program optimization - kann er auch funktionen ueber Uebersetzungseinheiten hinweg inlinen.

    prinzipiell immer dem compiler vertrauen...

    0
  • X

    Shade Of Mine schrieb:

    Das inline keyword dagegen gibt es ja nur wegen der ODR und hat keine performance Wirkung. Je nachdem wie gut der Compiler ist - der VC++ kann zB whole program optimization - kann er auch funktionen ueber Uebersetzungseinheiten hinweg inlinen.

    prinzipiell immer dem compiler vertrauen...

    Dh also kurz gesagt das das Keyword inline keinerlei Auswirkung hat, also es egal ist ob ich "inline void myfunc(){};" oder "void myfunc(){};" verwende?

    0
  • A

    Xebov schrieb:

    Dh also kurz gesagt das das Keyword inline keinerlei Auswirkung hat

    Nö. Es legt dem Compiler nahe, die Funktion zu inlinen. Ob er das tut, und ob diese Empfehlung Kriterium für seine Entscheidung ist, bleibt aber ihm überlassen.

    0
  • X

    audacia schrieb:

    Xebov schrieb:

    Dh also kurz gesagt das das Keyword inline keinerlei Auswirkung hat

    Nö. Es legt dem Compiler nahe, die Funktion zu inlinen. Ob er das tut, und ob diese Empfehlung Kriterium für seine Entscheidung ist, bleibt aber ihm überlassen.

    Ok danke für die Aussage bin bisher imemr davon ausgegangen das inline für den Compiler sehr viel bindender ist.

    0
  • S

    audacia schrieb:

    Xebov schrieb:

    Dh also kurz gesagt das das Keyword inline keinerlei Auswirkung hat

    Nö. Es legt dem Compiler nahe, die Funktion zu inlinen. Ob er das tut, und ob diese Empfehlung Kriterium für seine Entscheidung ist, bleibt aber ihm überlassen.

    Nur wenn der Compiler dumm ist.
    Moderne Compiler verwenden inline nur um zwischen internal und external linkage zu unterscheiden...

    0
  • B

    Nur das beobachtbare Verhalten eines Programms ist verbindlich. Optimierungen gehören nicht dazu (Ausnahme sind solche Dinge wie Return-Value Optimization, die beoachtbar sind, und deshalb eigentlich nicht unter Optimierungen im eigentlichen Sinne fallen). Es bleibt also für 'inline' nur die Auswirkung auf die One-Definition-Rule.
    Mit einem traditionellen Übersetzungsmodell (d.h. der Compiler erzeugt verschiebbaren Maschinencode in Objektdateien, der Linker bindet diese zu einem ausführbaren Programm zusammen) ist eine Funktion, die in einer anderen Übersetzungseinheit definiert wurde, für den Compiler nicht sichtbar, kann also nicht geinlinet werden. 'inline' ermöglicht es, die Funktion in einem Header zu definieren, so dass sie in jeder ÜE, die sie aufruft, sichtbar ist, und also geinlinet werden kann. Hat man aber ein Übersetzungsmodell, in dem die Aufgaben von Compiler und Linker flexibler verteilt oder verschränkt sind (=> Link-time code generation, Whole program optimization), wird sowas wieder möglich.

    Shade, inline-Funktionen haben nicht automatisch internal linkage. Wo hast du das denn her?

    0
Anmelden zum Antworten