Geschwindigkeit von Schleifen

[himitsu]

Bei Schleifen mit sehr vielen Durchläufen und mit sehr wenig Code darin, fällt das schon auf, aber sonst sollte man sich bei Schleifen einfach auf deren Funktion/Verwendung beziehen.

[p80286]

Zitat von Dejan Vu:

War da nicht mal was, dass der Vergleich auf 0 schneller ist, als der Vergleich auf '<Variable>'?

Jain, beim Vergleich auf null kannst Du das Register gleich mit 0 vorbelegen und mußt Dir nicht erst einen Wert aus dem Speicher angeln.

Aber wenn mann nicht Zeitkritisch arbeitet ist das zu vernachlässigen.

Gruß
K-H

[Stevie]

Interessant wirds eh erst dann, wenn man betrachtet, was innerhalb der Schleife geschieht.
Denn das entscheidet darüber wie ein Compiler entsprechende Optimierungen (z.B. loop unrolling) durchführen kann.

[Insider2004]

Verfalle nicht in den Optimierungswahn. Du verlierst Zeit ganz woanders. Z.B. in schwachsinnigen Programmstrukturen.

[WM_CLOSE]

Man sollte auch nicht ganz vergessen, dass der Prozessor selbst auch noch eine Rolle spielt. Eine Assembleranweisung hat ja bei modernen Mikroprozessoren nicht immer die selbe Ausführungsgeschwindigkeit. Stichworte sind Pipelining, Out-of-order execution, Branch Prediction und Caching.
Der Vergleich mit 0 ist üblicherweise deshalb schneller, weil man keine Variable zusätzlich ins Register laden muss.

Einige Schlüsse kann man auch aus diesem Wikipedia Eintrag ziehen.

Insgesamt kann man aber sagen, dass eine Optimierung auf Assemblerebene oder die Auswahl der "schnellsten" Schleife heute kaum noch nenneswerte Vorteile bringt.
Für rechenintensive Dinge ist heute eher Multithreading oder GPU processing angesagt. Für andere Dinge vielleicht ein intelligentes Caching oder ganz allgemeine Ablauf-Optimierungen.

PS: Solltet ihr neben den Intel Prozessoren auch andere targets haben, müsstet ihr die Optimierung sowieso für jeden Prozessortyp einzeln planen.

[OlafSt]

Das betrifft nicht nur den Unterschied zwischen Intel- und AMD-CPU. Bereits innerhalb der CPUs gibt es gravierende Unterschiede. So war damals z.B. der Aufschrei riesengroß, als die etablierte Pipelining-Technik des 80486 durch die veränderte Out-of-Order- und BP-Technik des Pentium ersetzt wurde.

Konsequenz daraus war, das manche Programme auf dem Pentium - trotz höherer Taktrate - langsamer liefen als auf einem 486. Die 486-Optimierung lief dem Design des Pentium schlicht "gegen den Strich".

[TRomano]

In hochoptimierten Routinen (purer Assembler in mathematischen Berechnungen mit millionenfacher Wiederholung z.B. Videokomprimierung o.ä.) macht das vielleicht Unterschiede, auch hier spielen unterschiedliche Implementierungen der Prozessorbefehle eine Rolle, aber auch nur, wenn man die einzelnen Takte zählt ... In einem Standard-Programm hat das nicht zu suchen, denn entscheidend ist was und wieviel in der Schleife passiert. Da ist (immer) Optimierungspotential vorhanden, vielleicht nicht bei zwei Additionen in einer Zeile ...