Rekursion vs. Iteration

[negaH]

Die Eingangsfrage ist ob rekusive oder iterative Umsetzungen eines Algos besser oder schlechter ist.

Man kann nun Äpfel mit Birnen vergleichen oder unsachlich argumentieren (zb. was hat Assembler damit zu tuen, oder was hat die Implementierung von Windows damit zu tuen, oder welche Relevanz hat eine Diskussion wenn man zb. für Fibonacci einen komplett anderen Algorithmus als Lösung vorschlägt und das als Basis für eine Begründung wählt um die iterative Methode zu untermaueren ?)

Der einzige Grund warum eine rekursive Lösung unter Umständen einen leichten Performance-/Speicheroverhead hat liegt in der Rechnerarchitektur begründet, ansonsten wird es zwischen beiden keinen Unterschied geben.

Wer sich mit programmierbarer Hardware, also FPGAs auskennt weiß das man dort zb. mit den Sprachen VHDL, Verilog oder Abel sehr wohl ein Problem iterativ wie auch rekursiv beschreiben kann. Die nachfolgende Synthese wird in beiden Fällen das exakt gleiche Resultat erzeugen.

Die Unterscheide zwischen beiden sind also begründet in der Architektur der Hardware und nicht im Theoretischen. Auf zb. FPGAs verhalten sich beide gleich, benötigen identische Resourcen und sind identisch performant. Auf ASICs ändert sich dieses Verhältnis, aber je umfangreicher die Berechnungen werden desto mariginaler wird dieser Unterschied.

Ergo: man kann das iA. vernachlässigen und die Prioritäten anders legen. Nämlich auf Verständlichkeit und damit Wartbarkeit. Das Ändern des Algos., zb. ersetzen durch einen besseren, wird in fast allen Fällen bessere Resultate erzielen als sich auf diese mariginalen Unterschiede zu stürzen.

@Gammatester:

dein Vergleich hinkt: du vergleichst zwei unterschiedliche Lösungswege miteinander und schließt daraus das die iterative Version von Vorteil wäre.

Gruß Hagen

PS: übrigens berichte ich hier aus meinem 25jährigen Erfahrungsschatz und vertrete hier nur eine Meinung. Wer mich kennt weiß das ich der Letzte bin der nicht aus jedem Stück HW das letzte an Peformance rauszuholen versucht, und dh. eben auch das man einen Vergleich zwischen beiden Implementierungsmöglichkeiten praktisch durchführt.