Wann macht es Sinn inline zu nutzen?
-
Was der TE wissen möchte: Wann entscheidet man sich, Funktionen im Header zu definieren?
Die Antwort ist aber nicht wirklich befriedigend: Wenn sie kurz sind und öfters benutzt werden. Aber das wusstest du sicherlich schon.
Ich verfahre nach der Regel "Im Zweifelsfalle eher inline" und fahre damit ziemlich gut. Wenn es wirklich drauf ankommt, kann man ein kritisches Codesegment (Profiler!) auch mal ohne Inline ausprobieren, da ein paar Effekte Vorstellbar sind, bei denen Code durch inline langsamer wird (dann wenn eine Funktion in einem Code öfters aufgerufen wird und durch das häufige Inlining der resultierende Maschinencode zu lang wird für einen der Zwischenspeicher in der CPU). Da man normalerweise bloß ungefähr eine solche Stelle pro Programm haben sollte, ist das keine große Arbeit.
Der Nachteil von inline (mehr Compilezeitabhängigkeiten) greift bei geschwindigkeitskritischen Programmen meistens nicht, da der Code insgesamt doch oft eher klein ist und selbst ein kompletter Rebuild nur Sekunden bis Minuten benötigt. Falls das Projekt nicht geschwindigkeitskritisch ist, dann braucht man auch nix inline zu machen, höchstens vielleicht triviale Einzeiler, die man niemals wieder ändern muss.
-
Danke, deine Erklärung hat mir schon geholfen. Bei mir geht es um Raytracing, also um genau zu sein auch um die verschiedenen Optimierungsstufen von normaler Deklaration/Definination über Inlining bis zum Schluß SIMD in Assembler. Ist alles nur ein Lernprojekt, aber zu jeder Stufe hole ich mir gerne Expertenmeinungen ein, da ich mir ein paar Sachen schon denken kann, aber so einiges doch übersehe.
-
Man sollte noch sagen, dass der Compiler sehr wohl inlinen kann wenn die Funktion nicht in einem Header steht.
-
Wär das nicht für den Linker?
-
Ach ja, wie das? Er sieht doch immer nur eine Einheit? Ist nicht der Linker das Programm welches erst wieder modulübergreifenden Zugriff hat?
-
Lichtweite schrieb:
Ach ja, wie das? Er sieht doch immer nur eine Einheit? Ist nicht der Linker das Programm welches erst wieder modulübergreifenden Zugriff hat?
Richtig, moderne Compiler/Linker unterstützen Link-Time Code Generation, ich denk der Name ist relativ selbsterklärend...
-
Diese Funktion macht dann das manuelle Inlining obsolet?
-
Der Punkt ist, dass der Zweck von inline, wie cooky451 schon gesagt hat, heutzutage eben vor allem die Ausnahme von der One Definition Rule ist. Verwend inline, aber verwend es mit Bedacht. Tu nicht einfach überall ein inline davor, in dem Glauben, dass das dann irgendwie magisch die Performance verbessert. Aber gut, der Rat gilt eh unabhängig davon, ob der Compiler jetzt LTCG unterstützt oder nicht...
Lichtweite schrieb:
[...] bis zum Schluß SIMD in Assembler.
Wenn du nicht gerade vor hast, weite Teile in Assembler zu schreiben, würde ich mir an deiner Stelle überlegen, ob es nicht besser wäre, entsprechende Intrinsics zu verwenden, statt Assembler. Zumindest Inline Assembler ist alles andere als optimal was Performance betrifft, da es den Compiler zwingt, rundherum den Optimizer abzuschalten. Und MSVC z.B. unterstützt für x64 etc. auch gar kein Inline Assembler mehr...
-
Lichtweite schrieb:
Diese Funktion macht dann das manuelle Inlining obsolet?
Ja ziemlich. Aber so ganz der Superhit ist es nicht, da man dadurch sehr lange Linkzeiten bekommt (praktisch so lang wie ein ganzer Build ohne Link-Time Optimization (LTO), was sehr nervig sein kann. Daher bevorzuge ich besonders für Entwicklungsversionen einen Build ohne LTO. Damit die aber trotzdem akzeptabel schnell laufen, muss alles was inline werden soll in einen Header. Was übrigens nicht so Umstellung, da ich sowieso sehr viel mit Templates programmiere.
-
Danke euch für die sehr interessanten Infos. Die intrinsische Funktionen kommen auf jeden Fall auch mit auf die toResearch-Liste.
