Was ist schneller, Funktion oder Prozedure?

[SMO]

Zitat von dizzy:

Mh, find ich nun fast enttäuschend. Dann heisst Inlining dort tatsächlich nur Ersparnis des Calls, bzw. der Vorbereitung der Parameter, und den Optimizer kümmerts nicht?

Nein. Jetzt zum dritten Mal:
Ein "var" Parameter erzwingt eine Speichervariable. Da ist dann nichts mehr drin mit Registeroptimierung und so. Wenn man also solche Tests macht, dann bitte den einzelnen Testfällen (hier der Prozedur und der Funktion) jeweils ihre eigenen lokalen Variablen geben.

Delphi-Quellcode:

var
  i: Integer;
begin
  x(i);
  i := y;
end.

So kann es ja nichts mit der Optimierung werden. Denn erstens ist i hier keine lokale Variable (wird also so oder so auf eine Speicherzelle abgebildet) und zweitens wird i für x und y benutzt, wobei x verhindert, das i auf ein Register statt Speicherzelle abgebildet wird.

So ist es besser:

Delphi-Quellcode:

procedure Test;
var
  ergx, ergy: Integer;
begin
  x(ergx);
  ergy := y;
end;

Mit inlining wird "ergy := y" hier total wegoptimiert.

[dizzy]

Zitat von SMO:

Zitat von dizzy:

Mh, find ich nun fast enttäuschend. Dann heisst Inlining dort tatsächlich nur Ersparnis des Calls, bzw. der Vorbereitung der Parameter, und den Optimizer kümmerts nicht?

Nein. Jetzt zum dritten Mal:
Ein "var" Parameter erzwingt eine Speichervariable. Da ist dann nichts mehr drin mit Registeroptimierung und so. Wenn man also solche Tests macht, dann bitte den einzelnen Testfällen (hier der Prozedur und der Funktion) jeweils ihre eigenen lokalen Variablen geben.

Um die Variable im Speicher/Register ging es hier garnicht. Es ging um das doppelt ausgeführte xor zum Erzeugen einer Null.

Zitat von SMO:

Delphi-Quellcode:

var
  i: Integer;
begin
  x(i);
  i := y;
end.

So kann es ja nichts mit der Optimierung werden. Denn erstens ist i hier keine lokale Variable (wird also so oder so auf eine Speicherzelle abgebildet) und zweitens wird i für x und y benutzt, wobei x verhindert, das i auf ein Register statt Speicherzelle abgebildet wird.

Ist wie gesagt garnicht Gegenstand der Diskussion

Zitat von SMO:

So ist es besser:

Delphi-Quellcode:

procedure Test;
var
  ergx, ergy: Integer;
begin
  x(ergx);
  ergy := y;
end;

Mit inlining wird "ergy := y" hier total wegoptimiert.

Das wäre dann aber grober Unfug, es sei denn D2005 tut auf einmal etwas ganz neues: Lokale Variablen mit 0 (nil) initialisieren. Ist dem so? Warum erkennt der Optimizer dann nicht auch, dass in der Prozedur x nur eine Null zugewiesen wird, und optimiert auch diesen Aufruf weg? Sowas meinte ich mit inkonsequent.

Zitat von tommie-lie:

Ist es sicherlich, aber es muss implementiert werden. Und da die Compilerautoren davon ausgehen, daß die Leute richtige Programme damit schreiben, sparen sie sich solche Prüfungen, weil nur in Spezialfällen davon ausgegangen werden kann, daß wirklich immer das selbe getan wird.

Wenn ich mich recht entsinne werden Ausdrücke wie "x := sqrt(2)*10;" vom Compiler ausgerechnet und als Konstante implementiert (weiss nicht mehr ob das bei Delphi oder C# der Fall war). Hier könnte man auch argumentieren: Warum rechnet es der Autor nicht selber aus? Kommentieren soll man bei "richtigen" Programmen eh, also kann da auch der Rechenweg dokumentiert sein wenn es um die Lesbarkeit geht =)
Und ich meine es wäre auch (MS)C# gewesen der eine Schleife in der immer nur ein konstanter Wert auf eine Variable addiert wird, im Vorhinein komplett ausrechnet und nur mit einer Konstanten ohne Schleife implementiert. Ein "Optimizer" der nur greift wenn ich eh schon recht optimal gecoded habe, ist imho ebenfalls inkonsequent . Zumal die Beispiele hier für den Coder offensichtliche Optimierungsmöglichkeiten zeigen. In dem obigen Beispiel geht es eher um die Ebene die der Programmierer erst im asm-code sehen könnte, und somit nichtmal direkten Einfluss darauf hat. Sicher sind die Methoden da oben sehr panne, da sie nur eine 0 schreiben. Aber es geht doch um das Konzept! Wenn so etwas einfaches nicht erkannt/verbessert wird, wie kann ich mich da noch darauf verlassen dass es in komplexeren Zusammenhängen besser läuft?

[jbg]

Aus den Newsgroups zum Delphi 2005 Optimizer (gilt auch für Delphi 1 bis 7).

[SMO]

Zitat von dizzy:

Das wäre dann aber grober Unfug, es sei denn D2005 tut auf einmal etwas ganz neues: Lokale Variablen mit 0 (nil) initialisieren. Ist dem so?

Nein. Und das ist kein grober Unfug. Der Compiler erkennt, dass "ergy" im Folgenden gar nicht mehr benutzt wird und auch dass das per inlining eingefügte y nichts tut, was auf den Rest des Programms Auswirkungen haben könnte. Also kann man sowohl den Aufruf von y als auch ergy hier ersatzlos streichen.

Zitat:

Warum erkennt der Optimizer dann nicht auch, dass in der Prozedur x nur eine Null zugewiesen wird, und optimiert auch diesen Aufruf weg? Sowas meinte ich mit inkonsequent.

Inkonsequent ja, aber auf andere Weise als du vielleicht meinst. Wenn man x mit inlining wie in obigem Beispiel aufruft, sollte der Compiler eigentlich auch erkennen, dass der Wert, der hier "ergx" zugewiesen wird, gar nicht benutzt wird, das ganze also wegrationalisiert werden könnte. Ich vermute, da verhindert der var Parameter wieder mal die Optimierung.

Delphi 2005 war die erste Version mit inlining, da kann man noch keine Perfektion erwarten. Ich habe gehört, dass es in Delphi 2006 schon ein bisschen verbessert worden ist.

[Flocke]

Zitat von dizzy:

Das wäre dann aber grober Unfug, es sei denn D2005 tut auf einmal etwas ganz neues: Lokale Variablen mit 0 (nil) initialisieren. Ist dem so? Warum erkennt der Optimizer dann nicht auch, dass in der Prozedur x nur eine Null zugewiesen wird, und optimiert auch diesen Aufruf weg? Sowas meinte ich mit inkonsequent.

Nicht wenn der Optimizer erkennt, dass ergy danach überhaupt nicht mehr benötigt wird - allerdings sollte er dann eigentlich auch erkennen, dass das für ergx ebenfalls gilt.

Nichtsdestotrotz - Delphi optimiert nicht so, wie es z.B. ein optimierender C- oder C++-Compiler tut. Dieser ist normalerweise auch dafür ausgelegt, total stupiden Code (wie in unserem Beispiel) zu optimieren - wenn sein Input nämlich von anderen Programmen wie lex oder yacc generiert wird, dann kann es sein, dass wirklich 10 mal "x = 10;" untereinander steht.

[mael]

Zitat von himitsu:

Wobei bei einer Exception sogar ein Var-Parameter seine Vorteile haben kann, da man diesen ja am Anfang der Prozedur (vor einer eventuellen Exception) auf einen bestimmten Wert setzen kann, wärend bei der Funktion im Exceptionfall der Rückgabewert verloren geht.

Der Sinn einer Exception ist gerade zu signalisieren das etwas schief gegangen ist und man eben nicht Rückgabewerte auswerten sollte. Was schief gegangen ist sollte durch den entsprechende Exception-Typ angegeben werden, und eventuell durch eine Fehlermeldung in der exception für den Benutzer präzisiert werden.

[tommie-lie]

Zitat von dizzy:

Wenn ich mich recht entsinne werden Ausdrücke wie "x := sqrt(2)*10;" vom Compiler ausgerechnet und als Konstante implementiert (weiss nicht mehr ob das bei Delphi oder C# der Fall war).

Berechnungen schreiben sich natürlicher und erhöhen die Übersichtlichkeit, wenn man sie aufsplitten kann und nicht vollständig aufgelöst im Code stehen, zum Beispiel wenn man Datenstrukturen aus Dateien liest, die sich aus mehreren Einzelkomponenten zusammensetzen. Außerdem lässt sich ein einfacher (und der des Delphi-Optimizers ist nur einfach) Matheparser relativ problemlos implementieren. Die Delphi-Hilfe habe ich grad' nicht zur Hand, aber sqrt() müsste Compiler-Magic sein, da ich die Funktion gerade nicht finden kann. Der Aufwand, für die durch Compilermagic implementierten Funktionen eine Auflösung zu schreiben, ist wohl nur gering. Ich schätze, in selbstgeschriebenen Funktionen, die du mit einem konstanten Parameter aufrufst, rechnet er das Ergebnis nicht aus.

Zitat von dizzy:

Und ich meine es wäre auch (MS)C# gewesen der eine Schleife in der immer nur ein konstanter Wert auf eine Variable addiert wird, im Vorhinein komplett ausrechnet und nur mit einer Konstanten ohne Schleife implementiert.

Das machen alle gängigen C++-Compiler so, und wenn's der C#-Compiler nicht machen würde, würde's der JIT machen.

Zitat von dizzy:

Wenn so etwas einfaches nicht erkannt/verbessert wird, wie kann ich mich da noch darauf verlassen dass es in komplexeren Zusammenhängen besser läuft?

Es ist in komplexen Vorgängen nicht besser


Edit: Total verquottelt.

[dizzy]

Zitat von Flocke:

Nicht wenn der Optimizer erkennt, dass ergy danach überhaupt nicht mehr benötigt wird - allerdings sollte er dann eigentlich auch erkennen, dass das für ergx ebenfalls gilt.

@SMO: Genau das war mein Punkt. Und _nur_ das.
Danke Flocke - ich hätts heut irgendwie nicht besser/direkter schreiben können

Zitat von Flocke:

Nichtsdestotrotz - Delphi optimiert nicht so, wie es z.B. ein optimierender C- oder C++-Compiler tut. Dieser ist normalerweise auch dafür ausgelegt, total stupiden Code (wie in unserem Beispiel) zu optimieren - wenn sein Input nämlich von anderen Programmen wie lex oder yacc generiert wird, dann kann es sein, dass wirklich 10 mal "x = 10;" untereinander steht.

Klingt logisch.

Zitat von tommie-lie:

Berechnungen schreiben sich natürlicher und erhöhen die Übersichtlichkeit, wenn man sie aufsplitten kann und nicht vollständig aufgelöst im Code stehen, zum Beispiel wenn man Datenstrukturen aus Dateien liest, die sich aus mehreren Einzelkomponenten zusammensetzen. Außerdem lässt sich ein einfacher (und der des Delphi-Optimizers ist nur einfach) Matheparser relativ problemlos implementieren. Die Delphi-Hilfe habe ich grad' nicht zur Hand, aber sqrt() müsste Compiler-Magic sein, da ich die Funktion gerade nicht finden kann. Der Aufwand, für die durch Compilermagic implementierten Funktionen eine Auflösung zu schreiben, ist wohl nur gering. Ich schätze, in selbstgeschriebenen Funktionen, die du mit einem konstanten Parameter aufrufst, rechnet er das Ergebnis nicht aus.

Oh, um sqrt() gings mir garnicht. Dummes Beispiel... Ich meinte generell einfach, dass konstante Teile einfacher mathematischer Formeln im Vorfeld ausgerechnet werden, und nicht zu Runtime wie es im Code steht. Was die Sache mit der Übersichtlichkeit angeht: Ich bin sogar schon dazu übergegangen tatsächlich konstante Teile einer Formel selber auszurechnen, vor allem wenn dazu eine Umstellung des ursprünglich geschriebenen nötig war, die ich Delphi nicht zutraute. Der Übersicht wegen steht die Ursprungsformel + Rechenweg als Kommentar dabei. Da jeder Code ohnehin kommentiert werden muss... . Aber das ist ja garnicht was ich will - eigentlich gehts mir ja darum das Konzept: "Könnte der Coder auch von Hand machen, aber ich tu's wenn er es nicht tut" von eben dieser Optimierung von mathem. Ausdrücken auf die gesamte Optmierung ausgeweitet würde. Das war Sinn und Zweck meiner obigen Aussage (Ich muss zugeben - ich drücke mich heut in der Tat nicht überall so eindeutig aus... sorry)

Zitat von tommie-lie:

Es ist in komplexen Vorgängen nicht besser

Da gehe ich von aus

[tommie-lie]

Zitat von dizzy:

Oh, um sqrt() gings mir garnicht. Dummes Beispiel...

Das dürfte aber so ziemlich der einzige Aufruf sein (ich weiß nicht, was es noch als Compiler-Magic gibt, Sinus und Kosinus und das war's glaub' ich auch schon), den der Compiler direkt zu Compile-Time ausrechnet

Zitat von dizzy:

Ich meinte generell einfach, dass konstante Teile einfacher mathematischer Formeln im Vorfeld ausgerechnet werden, und nicht zu Runtime wie es im Code steht.

Wie gesagt, ein mathematischer Parser ist recht einfach, vor allem der von Delphi. So kommt er zum Beispiel nicht damit klar, das konstante und variable Teile gemischt werden, also 2+x+3 kriegt er schonmal nicht hin. Ich weiß nicht, für welche Reihenfolge das gilt, aber wenn die Konstante auf einer bestimmten Seite der Variable ist, kriegt er's auch nicht hin. Also entweder x+2+3 oder 2+3+x wird ebenfalls nicht optimiert, so habe ich es zumindest von Delphi6 in Erinnerung.

Zitat von dizzy:

eigentlich gehts mir ja darum das Konzept: "Könnte der Coder auch von Hand machen, aber ich tu's wenn er es nicht tut" von eben dieser Optimierung von mathem. Ausdrücken auf die gesamte Optmierung ausgeweitet würde.

Das ist es, was viele andere Compiler machen. Obiges Beispiel mit der Schleife wäre Loop-Unrolling gewesen, und das kann heute so gut wie jeder bessere Compiler.

Zitat von dizzy:

Zitat von tommie-lie:

Es ist in komplexen Vorgängen nicht besser

Da gehe ich von aus

Da brauchst du nicht von ausgehen, es ist so


Edit: Irnkwie krieg' ich das mit dem Quoten nicht auf die Reihe...
Edit2: