Inline-Funktionen mit Schleifen, switch und goto
-
deine information ist veraltet. Die Compiler entwickeln sich ständig weiter. vor 8 Jahren waren Funktionen mit Loops noch ein Problem, heute ist man aber ein paar Jahre weiter.
Der alter Borland Compiler war einer der letzten die loops nie geinlined haben. Aber das war 2000 oder so. Mittlerweile sollte auch Borland etwas weiter sein
Generell sind alle Infos die du über die Optimierungen von Compilern liest hoffnungslos veraltet. Da 1-2 Jahre später die Informationen keinen Cent mehr Wert sind. Einzige halbwegs vernünftige Info bekommt man beim Compiler Release.
Deshalb gilt: Bei Performance Fragen: zuerst Messen, dann Entscheiden.
-
Kleiner Zusatzhinweis: "inline" kann man durch ein Makro immer erzwingen!
-
Ah, danke für die ausführlichen Antworten! Kann man denn irgendwie herausfinden, wie der Compiler es getan hat? Ob er eine von mir als Inline gekennzeichnete Funktion als inline kompiliert hat? Oder ist man nur auf "ist schneller geworden, also wurde geinlined - ist nicht schneller geworden, also wurde nicht geinlined"-Abschätzungen angewiesen?
Viele Grüsse
Ewgenij
-
Wenn es dich wirklich interessiert, was der Compiler aus deinem Code gemacht hat, mußt du dich ein wenig mit Assambler auskennen und das fertige Programm betrachten - wenn du an der Stelle des Funktionsaufrufes eine Reihe von push-Befehlen (für die Parameter und Rücksprungadresse) und einen 'call funcname' siehst, hat der Compiler sich gegen das Inlining entschieden.
@Hugo: #define-Makros sind etwas völlig anderes als inline-Funktionen. Und in C++ sollte man die Verwendung des Präprozessors auf ein Minimum beschränken.
-
Was ist denn schlimm an Makros? Wenn sie den Code schneller machen können. Klar, da gibt es keine Typüberprüfung und die Syntax ist was anders, aber wenns dadurch schneller wird?
Und das mit dem Inlinen, ich kann also das Inlinen nicht immer erzwingen. Kann man sich denn auf den Compiler verlassen, dass wenn er sich meiner inline-Anweisung widersetzt hat, es auch tatsächlich keinen Sinn machen würde? Ich meine, so schlau kann der doch nicht sein
-
Ewgenijkkg schrieb:
Oder ist man nur auf "ist schneller geworden, also wurde geinlined - ist nicht schneller geworden, also wurde nicht geinlined"-Abschätzungen angewiesen?
inline bedeutet nicht schneller. nur weil etwas inline ist, sparst du dir zwar den funktionscall und den austritt - ABER es kostet dich etwas:
du hast dadurch mehr code der eventuell schlechter in den cache wandern kann. es gibt da viele kriterien die entscheiden ob etwas inline schneller ist oder nicht.deshalb: lass den compiler entscheiden. da laufen so komplexe abschätzungen intern, die kannst du kaum selber vernünftig nachvollziehen.
wenn dich interessiert ob der compiler inlined - schau dir den asm code an...
-
Was der Compiler inline machen kann oder nicht, das kommt auf den Compiler drauf an.
Schleifen gehen auf jeden Fall mit einigen Compilern, ich habe schon Funktionsaufrufe mit mehreren Schleifen und mehrere Aufrufe "tief" komplett wegoptimiert gesehen - in Fällen wo man die inline Funktion mit Konstanten füttert und die Funktion keine komplizierten Nebeneffekte hat.
-
Ewgenijkkg schrieb:
Was ist denn schlimm an Makros? Wenn sie den Code schneller machen können. Klar, da gibt es keine Typüberprüfung und die Syntax ist was anders, aber wenns dadurch schneller wird?
Erstmal ist es nicht gesagt, daß Inlining das Programm wirklich schneller macht. Und zweitens ist der Präprozessor noch dümmer als der Compiler - und ein Makro so zu schreiben, daß es sich wirklich wie eine Funktion verhält, ist eine Kunst für sich.
-
Ewgenijkkg schrieb:
Was ist denn schlimm an Makros? ...da gibt es keine Typüberprüfung und die Syntax ist was anders, ...
Die "Syntax" ist gar nicht das Problem, sondern dass der Compiler etwas Anderes zu sehen bekommt als der Programmierer. Ich habe meine leidigen Erfahrungen mit Makros gemacht und gelernt: Sie sind in 99% der Fälle den Ärger, den man hinterher damit hat nicht wert und beißen einen hinterher in den Ar***.
Bei "Hack&Forget"-Programmen mag der Prozentsatz niedriger sein, aber bei Programmen mit Projektcharakter (Wartung, regelmäßige Überarbeitungen, mehrere Entwickler, ...) trifft das zu.
... mal ganz davon abgesehen, dass der Ansatz sehr nach "premature optimization" klingt (die ebenfalls aus Erfahrung schlecht ist).
Gruß,
Simon2.
-
Ewgenijkkg schrieb:
Was ist denn schlimm an Makros? Wenn sie den Code schneller machen können. Klar, da gibt es keine Typüberprüfung und die Syntax ist was anders, aber wenns dadurch schneller wird?
Dir sollte eigentlich selbst klar sein, dass das ein besch*ssenes Trade-off wäre. Abgesehen davon haben die andere ja schon alles gesagt. Generell gilt: Moderne Compiler können ganz gut entscheiden, was am effizientesten ist. Man sollte die Inline-Entscheidung daher ruhig dem Compiler überlassen. Im Fall der Fälle gibt's dann immer noch '__forceinline' (und Co.).
Ich verwende 'inline' eigentlich nur zur Wahrung der ODR bei Header-Bibliotheken und nie aus Performance-Gründen.
