Was ist schneller, Funktion oder Prozedure?

[SMO]

Zitat:

Zitat von dizzy

Daher schrieb ich ja auch, dass es hier doch sehr stark auf den Kontext ankommt. Allein schon wenn man nicht "lose" Funktionen, sondern Klassenmethoden aufruft ändert sich einiges. Auch was sonst drumherum passiert kann das ganze Bild verändern. Eine pauschale Antwort ist hier also kaum machbar.

Eben. Deswegen bring ein Konkretes ASM-Beispiel kaum etwas. Je nach Kontext des Funktionsaufruf kann der generierte Code auch so aussehen:

Code:

function y: Integer;
----------------------
  CALL  y
  XOR   eax, eax   // Inhalt von eax 0 setzen
  RET              // Rücksprung

  MOV  esi,eax   // Zuweisung an lokale Variable erg, die sich nun im Register esi befindet

Das wäre nochmal ein Stückchen schneller, da man hier keinen Speicherzugriff hat. Unter Umständen kann der letzte Befehl "MOV esi,eax" sogar entfallen, nämlich dann wenn "erg" im Folgenden auf das Register eax abgebildet wird.

Wie ich oben bereits schrieb, Aufrufe mit var Parameter erzwingen immer eine Speichervariable. Deshalb kann man schon eine pauschale Aussage machen, nämlich: bei primitiven Datentypen Funktionen benutzen, kann der Optimierung dienlich sein.

[RavenIV]

Zitat:

Zitat von SMO

Wie ich oben bereits schrieb, Aufrufe mit var Parameter erzwingen immer eine Speichervariable. Deshalb kann man schon eine pauschale Aussage machen, nämlich: bei primitiven Datentypen Funktionen benutzen, kann der Optimierung dienlich sein.

eigentlich sollte man immer funktionen verwenden und auch immer ein wert zurückgeben.
denn auch in einer procedure kann mal etwas schiefgehen und das bekommt der aufrufer dann nicht mit.

[himitsu]

Zitat:

Zitat von RavenIV

eigentlich sollte man immer funktionen verwenden und auch immer ein wert zurückgeben.
denn auch in einer procedure kann mal etwas schiefgehen und das bekommt der aufrufer dann nicht mit.

Ob da nun als Parameter, oder Result-Parameter ... ist da doch egal?
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.

Und wiso soll der Benutzer ausgerechnet nur bei Prozedur nichts mitbekommen, wenn was schiefgeht?

[tommie-lie]

Zitat:

Zitat von RavenIV

eigentlich sollte man immer funktionen verwenden und auch immer ein wert zurückgeben.
denn auch in einer procedure kann mal etwas schiefgehen und das bekommt der aufrufer dann nicht mit.

Und wie kriegt er es üblicherweise bei Funktionen mit? Richtig, Fehlercode im Ergebnis speichern. Das gleiche kannst du auch bei Prozeduren machen. Ansosnten wirf halt 'ne Exception, wenn du den Rest des Codes nicht so narrensicher schreiben willst, das tatsächlich nur eine Exception aus dem Betriebssystem dazwischenfunken könnte.

[Tubos]

Zitat:

Weil es den Prozeduren des Threaderstellers gleicht

Achja!
Rückgabe per parameter... hab ich komplett vergessen. War wohl ein Blackout ;)

[Khabarakh]

Zitat:

Zitat von dizzy

Da kann der Optimierer nicht dran - mit Inlining hätte er hier also sogar einen doppelten Vorteil: Einmal spart man sich den CALL, und zum zweiten ließe sich eine ganze Anweisug wegoptimieren. Ferner würde sich dann sogar erkennen lassen, dass v immer der selbe Wert zugewiesen wird, und der ganze Kram incl. Schleife könnte rausgeschmissen werden, und v ein einziges Mal mit einer Konstanten belegt... jaja, ich war schon immer Fan von Inlining ^^

Und hier der Test dazu:

Delphi-Quellcode:

procedure x(var AValue: Integer); inline;
begin
  AValue := 0;
end;

function y: Integer; inline;
begin
  Result := 0;
end;

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

http://img237.imageshack.us/img237/7222/temp2nh.png
Mein Wissen über Assembler tendiert zwar gegen null, aber das sieht für mich ziemlich ähnlich aus :stupid: . Die Geschwindigkeiten sollten wohl auch nah beieinander liegen :stupid:² . Von anderen Optimierungen sehe ich aber nichts.

[dizzy]

Zitat:

Zitat von Khabarakh

Mein Wissen über Assembler tendiert zwar gegen null, aber das sieht für mich ziemlich ähnlich aus :stupid: . Die Geschwindigkeiten sollten wohl auch nah beieinander liegen :stupid:² . Von anderen Optimierungen sehe ich aber nichts.

Ich habe von einer Schleife gesprochen. Mindestens ein Mal _muss_ das ja gemacht werden um eine Null zu erzeugen. Dein Test passt somit nicht zur Vermutung ;)

\\edit: Jedoch hast du insofern Recht, als dass das xor für die 2. Codezeile über ist, ja. Da scheint mir der Optimizer kaum optimal zu sein. Mit ein Grund weswegen ich scharf darauf bin manche Dinge in asm selbst von Hand machen zu können - ich kann dem Automatismus also nicht voll vertrauen :D

[Khabarakh]

Zitat:

Zitat von dizzy

\\edit: Jedoch hast du insofern Recht, als dass das xor für die 2. Codezeile über ist, ja. Da scheint mir der Optimizer kaum optimal zu sein.

Genau, das habe ich gemeint. Die Schleife ändert übrigens auch nichts, es wird trotzdem 20.000-mal geXORt.

[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? In meinen Augen inkonsequent. In einem komplexeren Zusammenhang könnte ich ja verstehen dass da sicher nicht alles super-tip-top optimiert werden kann, da die Zusammenhänge sehr komplex werden können. Aber in so einem einfachen Fall dürfte das sehr wohl per Software erkennbar sein.
Aber nun back to Topic :stupid:

[tommie-lie]

Zitat:

Zitat von dizzy

Aber in so einem einfachen Fall dürfte das sehr wohl per Software erkennbar sein.

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.