inline wirklich 100% genauso schnell wie wenn ich den Funktionstext nochmal reinschreibe?

n/t

queer_boy

traust du dem compiler etwa nicht zu, zu einfachen textersetzungen fähig zu sein?

btw. soll es hier um inlining gehen (worüber du nicht wirklich kontrolle hast), oder um das schlüsselwort inline ?

queer_boy schrieb:

traust du dem compiler etwa nicht zu, zu einfachen textersetzungen fähig zu sein?

btw. soll es hier um inlining gehen (worüber du nicht wirklich kontrolle hast), oder um das schlüsselwort inline ?

Ich frage mich halt, ich hab wirklich teilweise überladene funktionen mit mehreren hundert zeilen (große switch anweisungen), und die will ich z.b. in ne inline funktion auslagern und dann in eine eigens dafür angelegte .h Datei speichern. Dabei geht es ja ausschließlich um Übersichtlichkeit, wenn das einen Geschwindigkeitsverlust zur Folge hat, lass ich es lieber in einer Datei

Der Compiler muss inline nicht befolgen. Und sehr wahrscheinlich optimierst du an der falschen stelle.

blalabald schrieb:

Der Compiler muss inline nicht befolgen. Und sehr wahrscheinlich optimierst du an der falschen stelle.

Es geht ja gar nicht um Optimierung, da der Quelltext jetzt so in einer Funktion steht, aber halt eine relativ große. Und die möchte ich in 3 inline Funktionen aufteilen, die Frage ist nur, ob das dann wirklich 100% genauso schnell ist..

also stellt euch das so vor:

function a()
{
  switch(xyz)
  {
    case 123:
    break;
    case 2342:
    break;
  }
}

Soll dann praktisch werden zu:

function a()
{
  xyzSwitcher(xyz);
}

#include "xyzSwitcher.h"

----
xyzSwitcher.h

inline function xyzSwitcher(int xyz)
{
  switch(xyz)
  {
    case 123:
    break;
    case 2342:
    break;
  }
}

Es geht mir hierbei wirklich nur um organisatorische Vereinfachung des Quelltexts und die prinzipielle Frage, ob ich dadurch einen Geschwindigkeitsverlust habe?

Nexus

NeWs0fTzzz schrieb:

Es geht mir hierbei wirklich nur um organisatorische Vereinfachung des Quelltexts und die prinzipielle Frage, ob ich dadurch einen Geschwindigkeitsverlust habe?

Du findest es also eine organisatorische Vereinfachung, wenn du statt einer lieber zwei Funktionen schreibst, von denen die eine nichts anderes tut, als die andere aufzurufen?
Ich frage mich sowieso, wie das geht, weil a() ja gar keine Parameter übergeben bekommt.

Oder wäre da noch mehr dabei, und du hast nur eine Kurzform des Codes aufgeschrieben? Dann solltest du mindestens das noch ein bisschen mehr ausführen, sonst versteht man nicht, was du organisatorisch vereinfachen willst.

Und wenn es dir nicht um Optimierung geht, was würde dich dann der Geschwindigkeitsverlust stören? Wieso versuchts du es überhaupt mit inline ? Es ist nämlich zweifelhaft, ob der Compiler inline überhaupt anwendet und wenn ja, ob die Inline-Funktion tatsächlich schneller ist.

es ist wahrscheinlich, dass du einen geschwindigkeitsverlust haben wirst. der compiler muss inline nicht befolgen und wird es in diesem wahrscheinlich auch nicht, wenn es mehr als 2 case-statements sind.

der verlust wird aber wahrscheinlich zu vernachlässigen sein. das geht ja schon in den bereich der mikrooptimierung, wenn gar nichts anderes mehr übrig bleibt.

@Nexus natürlich ist das extrem stark vereinfacht, stell dir vor da kommen je nach Bedingung 3 verschiedene switch anweisungen mit jeweils zig bis hunderten cases und genau diese 3 switch anweisungen wollte ich per inline funktion aufrufen.

Wie macht man das dann verlustfrei? Per Precompiler Makro? Die Funktion wird wirklich oft aufgerufen (ist ein Onlinerollenspiel und die Funktion switched praktisch je nach benutztem Objekt die dann erfolgenden Aktionen), und da will ich nicht unnötig CPU verschwenden für zusätzliche Funktionsaufrufe O.o

Richtig viel CPU fressen sowieso die Wegfindungsroutinen

Nexus

Wenn du sowieso immer gerade eine Zahl einfügst (also z.B. case 421: ), dann brauchst du eigentlich keine Makros. Die sind höchstens zur Übersichtlichkeit, wobei sie auch Nachteile mit sich bringen (wurde in einem anderen Thread gerade diskutiert, ich glaube, im C-Forum).

Ich glaube, es gibt Alternativen zu switch, leider kenne ich mich da auch nicht aus (Boost? std::map?)...

Du könntest eventuell ein wenig Rechenzeit gewinnen, wenn du Fälle nach Häufigkeit sortierst, d.h. die cases am Anfang, die am meisten vorkommen. Dann müssen nicht immer alle Fälle durchgegangen werden...

Generell würde ich sagen, du solltest eher versuchen, die Algorithmen zu optimieren, ich bezweifle stark, dass du mit inline viel gewinnen kannst.

Nexus irgendwie verstehst du gar nicht so recht was ich will..

Erstens will ich gar nix optimieren von dem Switch Statement, das ist super so?!?
Und warum bitte schön sollte es was bringen oft benutzte cases nach vorne zu machen? Ich mein Schon mal was von jumptables gehört?

Mir ging es um die Frage, ob ich dieses Switch statements in andere Dateien auslagern kann, aus rein ÄSTHETISCHEN Aspekten, und ob das ohne Geschwindgkeitsverlust möglich ist!

Frage: würde das #include statement so funktionieren?:

Datei main.cpp:

int main(int argc, char *argv[])
{
  #include "outsourcedfunction.h"
}

Datei outsourcedfunction.h:

std::cout << "Dies ist der ausgelagerte Funktionsbody" << std::endl;

Das wäre zumindestens eine Lösung für mein Problem hehehe..

Nexus

Tut mir echt leid, dass ich dich falsch verstanden habe, dabei versuche ich nur zu helfen... Ich hoffe, dieses Mal ist meine Antwort brauchbarer.

Das #include funktioniert so, aber ob das so sauber ist und der Übersichtlichkeit dient, musst du selber wissen... Allerdings gibt es da sicher keinen Geschwindigkeitsverlust, da ja einfach der Code kopiert wird. Ansonsten du kannst ja einfach die Inline-Funktion in einen Header auslagern und diesen Header inkludieren. Ich denke, dann ist eher erkennbar, was gemacht wird, als wenn irgendwelche Anweisungen scheinbar global da drin stehen. Ein guter Compiler sollte bei einer Inline-Funktion auch den Text kopieren, wenn sonst ein Geschwindigkeitsverlust entsteht. Sicher bin ich mir da allerdings nicht.
Aber wie gesagt, deine Entscheidung.

Und nebenbei: Wird bei switch() nicht Fall für Fall durchgearbeitet? Wieso ist es dann so, dass ohne break; gleich der nächste Fall dran kommt?

Nexus schrieb:

Und nebenbei: Wird bei switch() nicht Fall für Fall durchgearbeitet? Wieso ist es dann so, dass ohne break; gleich der nächste Fall dran kommt?

Ich wollte dich jetzt nicht anmachen dass du das falsch verstanden hast, ist schon okay :p

simpel, die anweisungen werden hintereinander in den Maschinencode geschrieben (Maschinencode ist ja immer linear) und dann wird einfach per Jumptable zum richtigen Case gesprungen.. switch::case ist teilweise schon bei 2!!! cases schneller als if..else und ab 3 sowieso!

und warum er ohne break weitermacht? Ganz einfach, die case anweisungen stehen wie gesagt ja hintereinander. Ohne das break würde er die alle nacheinander arbeiten, das break ist dann praktisch die anweisung in maschinensprache hinter das ganze switch case konstrukt zu springen

und ja das hatte ich ja eigentlich vor, die funktion per header auszulagern, als inline zu includen. Die Frage ist halt ob er das wirklich macht, ob da einer genaueres weiß.

Nexus

NeWs0fTzzz schrieb:

Nexus schrieb:

Und nebenbei: Wird bei switch() nicht Fall für Fall durchgearbeitet? Wieso ist es dann so, dass ohne break; gleich der nächste Fall dran kommt?

Ich wollte dich jetzt nicht anmachen dass du das falsch verstanden hast, ist schon okay :p

Okay, vielen Dank für die Erklärung (sorry, ich hab mich bisher auch nicht ausführlich dafür befasst).

NeWs0fTzzz schrieb:

und ja das hatte ich ja eigentlich vor, die funktion per header auszulagern, als inline zu includen. Die Frage ist halt ob er das wirklich macht, ob da einer genaueres weiß.

Bist du dir überhaupt sicher, dass eine normale Funktion langsamer ist? Ich denke, Funktionen haben ja nicht nur den Vorteil der Übersichtlichkeit, sondern können auch schneller sein als der Code selber... Oder ist das einzige Argument gegen Inline-Funktionen ein zu grosser Quellcode?

An deiner Stelle würde ich das einfach mal ausprobieren. Miss doch die Zeit, die für die Ausführung benötigt wird. Dann kannst du auch schauen, ob mit einer ausgelagerten Inline-Funktion ein Geschwindigkeitsverlust entsteht.

queer_boy

NeWs0fTzzz schrieb:

Wie macht man das dann verlustfrei? Per Precompiler Makro? Die Funktion wird wirklich oft aufgerufen (ist ein Onlinerollenspiel und die Funktion switched praktisch je nach benutztem Objekt die dann erfolgenden Aktionen), und da will ich nicht unnötig CPU verschwenden für zusätzliche Funktionsaufrufe O.o

wenn du tatsächlich wert auf die organisation deines codes legst, solltest du von switch auf sprachunterstützte polymorphie (virtual) umsteigen.

praktisch wirst du keinen geschwindigkeitsverlust haben, weder durch einen funktionsaufruf noch durch ein umsteigen auf alternativen zu dem hässlichen switch-block. ohne jetzt mehr darüber zu wissen, wieviel du schon auf einer höheren ebene optimiert hast, hört sich der ganze thread so an, wie wenn du versuchen würdest von berlin nach paris zu kommen und dir dabei gedanken über den besten schuh dafür zu machen. warum nicht einfach mit sandalen ins flugzeug steigen?

Virtual wäre sowas von unpraktisch in dem Fall, aber danke queer_boy, dass du mir erzählen willst, wie ich richtig zu programmieren hab :p
Keine Sorge, ich weiß schon was ich tue, deswegen weicht doch bitte nicht die ganze Zeit vom Thema ab! Ich werde wahrscheinlich diese Include Methode nehmen, wenn jemand etwas besseres kennt, bitte Bescheid sagen.

Shade Of Mine

NeWs0fTzzz schrieb:

Virtual wäre sowas von unpraktisch in dem Fall, aber danke queer_boy, dass du mir erzählen willst, wie ich richtig zu programmieren hab :p
Keine Sorge, ich weiß schon was ich tue, deswegen weicht doch bitte nicht die ganze Zeit vom Thema ab! Ich werde wahrscheinlich diese Include Methode nehmen, wenn jemand etwas besseres kennt, bitte Bescheid sagen.

Lass es einfach sein.
Sorry wenn das hart klingt, aber lass dir von uns was sagen.

Was du hier machst ist einfach eine katastrophe.

Die Kosten eines Funktionsaufrufs sind laecherlich klein. Hier ist der komplett falsche Ansatz fuer optimierungen. #include fuer Code includes zu verwenden ist einfach nur unwartbar und es gibt kaum eine situation wo das Sinn macht.

lange switch Konstrukte deuten auf schlechtes Design hin. Es gibt selten eine Situation wo lange switches Sinn machen, idR ist polymorphie der richtige Ansatz. Und genau das ist der Punkt wo du ansetzen solltest.

Ich habe schon eine Menge Code geschrieben und nie waren die Kosten eines Funktionsaufrufs auch nur in der Naehe von relevant. Wobei, um ehrlich zu sein: einmal war das der Fall, das war ein dummer getter/setter der in engen loops aufgerufen wurde.

Und weisst du wie ich das optimiert habe? ich habe einen opcode cache installiert (war php code) und schon war die Sache erledigt.

eine funktion die sowieso laengere laufzeit von mehr als ein paar nanosekunden hat, kann locker die kosten eines aufrufs vertragen (die enorm gering sind).

die richtige variante waere sehr sehr viele kleine funktionen zu haben. die regel ist etwa so, dass jede Funktion die ueber 6 Zeilen Code enthaelt zu gross ist. Die meist angewandte regel sagt dass 10 zeilen code zuviel sind. Manche aktzeptieren auch noch 12 zeilen code. aber dann wird es schon langsam zu viel und ist nur noch in ausnahme situationen sinnvoll.

und solche ausnahme situationen kommen enorm selten vor. viele leute denken immer, dass sie sich in so einer ausnahme situation befinden, aber das ist so gut wie nie der fall...

Mädels langsam regt ihr mich auf. Nochmal zum mitschreiben:

Ich weiß was ich tue.
Ich will IMMER NOCH NICHT optimieren.
Nein, Polymorphie ist nicht der richtige Ansatz.

Also _BITTE_ hört auf mir vorschreiben zu wollen wie ich zu programmieren habe!
Ich möchte nur wissen wie man Funktionsteile OHNE Verluste in andere Dateien auslagern kann.

Mr X

#include oder mit Funktionen. Wobei ich zu Funktionen raten würde... Icludieren ist Meines Erachtens kein toller Stil. Ist Aber Ansichtssache. Includieren ist wahrscheinlich minimal schneller

camper

NeWs0fTzzz schrieb:

Ich weiß was ich tue.

Wenn dem so ist, müsstest du auch wissen, dass diese Frage in diesem Unterforum falsch platziert ist. Schließlich handelt es sich nicht um ein Sprachproblem sondern um das einer bestimmten Implementation - aus Sicht der Sprache allein ist die Fragestellung sogar völlig sinnlos.

camper schrieb:

NeWs0fTzzz schrieb:

Ich weiß was ich tue.

Wenn dem so ist, müsstest du auch wissen, dass diese Frage in diesem Unterforum falsch platziert ist. Schließlich handelt es sich nicht um ein Sprachproblem sondern um das einer bestimmten Implementation - aus Sicht der Sprache allein ist die Fragestellung sogar völlig sinnlos.

Naja eigentlich ist es doch ein Sprachproblem, nämlich welche Möglichkeiten dir Standardkonformes C++ für so eine Aufgabe gibt, und da fällt mir spontant nur #include oder eine inline Funktion ein..