Achtung. Optimierung beim Compiler

[DelTurbo]

Hi,

damit eventuell andere nicht in diese falle laufen poste ich mal was passiert wenn man die Optimierung an hat.

Eine gaaanz fiese sache ist, das schleifen rückwärts laufen können. Das spart ein cmp. In meinem fall ist das voll in die hose gegangen.

Beispiel:
Ich habe ein InUse = Array[0..100] of Boolean. Das wird von mehreren Threads genutzt. Und auch wieder frei gegeben. Mein Sourcecode war wie folgt.

Delphi-Quellcode:

for i:=0 to 100 do
begin
  if NOT InUse[i] then ....
end;

Ziel war es von "unten" einen leeren Slot zu suchen. Ich habe fast eine Stunde gebraucht bis ich rausfand das die schleifen rückwärts läuft. Man kann es nur im Assembler sehen.

Ändert man den Sourcecode wie folgt ab, läuft die schleife wieder richtigrum. Also von 0 bis 100

Delphi-Quellcode:

for i:=0 to 100 do
begin
  WriteLn(i);
  if NOT InUse[i] then ....
end;

Ich weiss nicht inwie weit diese sache bekannt ist. Auch habe ich eine frage dazu. Gibt es flags/parameter womit man teile des programms von der optimierung ausschliessen kann?

Gruss und danke im voraus

[s.h.a.r.k]

Schau mal hier.

Auf Delphi-Treff war mal ein guter Artikel dazu, finde den gerade aber nicht mehr.

PS: Thread solltest du auch ein einer T(Object)List verwalten, z.B.. Da hast du auch nicht das Problem einen freien Platz suchen zu müssen.

// edit
Soweit ich das noch weiß, optimiert der Compiler das dahingehend, da die CPU scheinbar leichter und schneller um 1 dekrementieren als inkrementieren kann. Aber einen Unterscheid sollte in deinem Programm nicht auftreten. Beim Debuggen findet du lediglich die "falschen" Werte, intern wird aber alles richtig ausgeführt.

// edit 2:
Hier, ganz unten findest du das auf Delphi Treff.

[jfheins]

Grund ist dass sehr einfach auf "=0" geprüft werden kann. ein "=100?" läuft also auf ein "x-100=0?" 'raus ;)

Aber eigentlich sollte die Compileroptimierung keine Änderung des Verhaltens zeigen - wie du richtig festgestellt hast, lässt der Compilrr die Schleife vorwärts laufen sobald es einen Unterschied macht (=> eine Ausgabe erzeugt o.ä.)

Kann mit
{O+} und {O-}
gesteuert werden

[JasonDX]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1027200)

Soweit ich das noch weiß, optimiert der Compiler das dahingehend, da die CPU scheinbar leichter und schneller um 1 dekrementieren als inkrementieren kann.

Nein, der Compiler optimiert die Schleife so, dass sie nicht von n..m, sondern von (n-m-1)..0 läuft. Da bei Operationen wie Inc- und Dekrementieren bereits das Zero-Flag gesetzt wird, wenn der Wert 0 wird, erspart man sich einen Vergleich pro Schleifendurchlauf.

Zitat:

Zitat von s.h.a.r.k (Beitrag 1027200)

Aber einen Unterscheid sollte in deinem Programm nicht auftreten. Beim Debuggen findet du lediglich die "falschen" Werte, intern wird aber alles richtig ausgeführt.

Ja, der Zugriff auf InUse[i] erfolgt in der richtigen Reihenfolge. Der Compiler speichert sich den Zeiger auf InUse[0], und inkrementiert diesen bei jedem Schleifendurchlauf, während der Index dekrementiert wird. Läuft insgesamt schneller, und das Array wird in der korrekten Reihenfolge abgearbeitet.

greetz
Mike

[hoika]

Hallo,

was mich eh interessiert.
Wieso hast du beim Debuggen die Optimierung angeschaltet ?


Heiko

[Luckie]

Wahrscheinlich, weil sie bei den Projektoptionen standardmäßig an ist.

[himitsu]

Über einige standardmäßige Sachen hatte ich mich ja schonmal beschwert.
- wenn standardmäßig auch noch Bereichsprüfungen, Überlaufprüfungen und Dergleichen aktiviert wären, dann gäbe es diesbezüglich wohl auch weniger Probleme bezüglich 0- und 1-Index, sowie Length()-1 usw.


Fakt ist einfach, daß man dem Debugger vergessen hat mitzuteilen, daß z.B. die Reihenfolge umzudrehen ist, bzw. daß der interne Wert anders interpretiert werden muß.

Bei Verwendung dieses Index wird er aber "richtig" angewand.
Sei es durch:

Delphi-Quellcode:

// dieses
for i := 0 to 10 do
  x := a[i];

// als
i := 10;
repeat
  x := a[10-i];
  Dec(i);
until {i = 0} ZeroFlag;

// oder 

i := 10;
p := @a[0]
repeat
  x := p^;
  Inc(p);
  Dec(i);
until {i = 0} ZeroFlag;

// oder (es gibt noch unzählige Möglichkeiten

[DelTurbo]

Zitat:

Zitat von jfheins (Beitrag 1027203)

Grund ist dass sehr einfach auf "=0" geprüft werden kann. ein "=100?" läuft also auf ein "x-100=0?" 'raus ;)

Ne, das ist so nicht richtig. Wie ich oben schrieb braucht es ein cmp (Assembler) weniger. Richtig rum sähe das so aus

mov [register+?],0 // Startwert
schleife:
inc [register+?] // Wert einen hochzählen
cmp [register+?],$5a // Vergleichen ob MAX erreicht ist.
jne schleife

nach der Optimierung sieht es so aus

mov [register+?],$5a // MAX Wert
schleife:
dec [register+?] // Einen vom MAX abziehen
jnz schleife // Wenn nicht 0 dann weiter

Das ist extra so "platt" geschrieben das auch leute die kein Assembler können es verstehen sollten.

Gruss

PS.: Danke, das mit dem {O+} und {O-} werde ich mir merken.

EDIT: Ich weiss nicht was ihr mit Debugger meint. Ich meine das CPU-Fenster. Da sieht man wirklich was abgeht.

[himitsu]

Zitat:

Zitat von DelTurbo (Beitrag 1027305)

PS.: Danke, das mit dem {O+} und {O-} werde ich mir merken.

Oder sieh dich mal in den Projektoptionen um. :zwinker::

Zitat:

Zitat von DelTurbo (Beitrag 1027305)

EDIT: Ich weiss nicht was ihr mit Debugger meint. Ich meine das CPU-Fenster. Da sieht man wirklich was abgeht.

Rate mal, wer dir Zugang zu diesem Fenster gewährt?

[DelTurbo]

Jo,

in den Projektoptionen habe ich das ja ausgemacht nachdem ich den salat gesehen habe. Es geht nur darum das man es dort z.b. Generell ausmacht und einzelne Proceduren optimiert. Oder halt andersrum.

Steht aber so auch in meinem ersten post.

Zitat:

Gibt es flags/parameter womit man teile des programms von der optimierung ausschliessen kann?