Codeoptimierung lieber abschalten

[Uwe Raabe]

Ohne einen Beleg dafür ist das nur Angstmacherei.

[TurboMagic]

Zitat:

Zitat von himitsu (Beitrag 1516998)

Einfach noch eine Config hinzufügen?

Release
Debug (wie Release, nur ohne Debuginfos)

Und dann kann man nochmal davon ableiten und Varianten mit/ohne Codeoptimierung hinzufügen,
oder, wie bereits erwähnt, dann das wenigstens in beiden Configs abschalten, damit man auch das debuggt, was auch der Kunde bekommt.

Alternativ mit externen Debuginfos kompilieren ... jenachdem ob die Debuginfodateien (TDS) daneben liegen, ist es mit oder ohne, aber die Programmdateien selber sind immer identisch.

Eine andere Alternative wäre, diese defines in eine Include Datei zu packen und diese per {$I MeineIncludeDatei.inc} in jeder Unit einzubinden.
Dann könnte man es wieder zentral ein/ausschalten.

[jaenicke]

Zitat:

Zitat von TomyN (Beitrag 1517001)

Ich meine gehört zu haben :?, dass im Optimierungsfalle Schleifen ggf. in die andere Richtung abgearbeitet werden, was zu 'Seiteneffekten' führen kann.

Zitat:

Zitat von Uwe Raabe (Beitrag 1517004)

Ohne einen Beleg dafür ist das nur Angstmacherei.

Das ist keine Angstmacherei, das ist wirklich so. Das ist aber auch kein Problem und nur im generierten Assemblercode sichtbar, da das nur passiert, wenn man die Schleifenvariable nicht verwendet. Beispiel:

Delphi-Quellcode:

procedure Test;
var
  i: Integer;
begin
  for i := 0 to 9 do
    ShowMessage(1.ToString);
end;

Der generierte Code sieht so aus:
Anhang 55709

//EDIT:
Ach ja, wenn man im Assemblercode nicht die Variable, sondern das Register anspricht, kommt man auch dran. Das kann jeder mit Optimierung testen:

Delphi-Quellcode:

procedure Test;
var
  i, b: Integer;
begin
  for i := 0 to 9 do
  begin
    asm
      mov b, ebx
    end;
    ShowMessage(b.ToString);
  end;
end;

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1517008)

Das ist keine Angstmacherei, das ist wirklich so. Das ist aber auch kein Problem und nur im generierten Assemblercode sichtbar, da das nur passiert, wenn man die Schleifenvariable nicht verwendet.

Ich weiß. Die Angstmacherei bezog sich auch eher auf das "Ich meine gehört zu haben" und "was zu 'Seiteneffekten' führen kann". Die Rückwärtsschleifen kommen ja nur dann zum tragen, wenn es eben keine unerwünschten Seiteneffekte dabei gibt.

[himitsu]

Zitat:

Zitat von TomyN (Beitrag 1517001)

Ich meine gehört zu haben :?, dass im Optimierungsfalle Schleifen ggf. in die andere Richtung abgearbeitet werden, was zu 'Seiteneffekten' führen kann.

Ja, die zählen manchmal rückwärts auf 0 runter, aber beim Zugriff wird das umgerechnet und schon stimmt es wieder.

Egal, ob aus dem

Delphi-Quellcode:

for i := 1 to 9 do
  Write(i);

der Compiler das macht.

Delphi-Quellcode:

for i := 8 downto 0 do
  Write(9 - i);

Am Ende kommt das Gleiche bei raus.

Aber kommt wer auf die saudumme Idee nach der Schleife auf i zugreifen zu wollen, dann ist er selbst Schuld.



@jaenicke:
Mit 64 Bit stirbt der Inline-Assembler eh aus.
Und wenn i mal nicht in ebx liegt, dann hat dein Code eh ein Problem.
Wenn du im Assembler auf "i" zugreifst, dann weiß der Compiler in welchem Register/Stack die Variable liegt und dass hier nicht optimiert werden kann/soll.

Auch mit Pointern kann man da Mist bauen.

Delphi-Quellcode:

for i := 0 to 9 { step 2 } do begin
  ShowMessage(i.ToString);  // 0 2 4 6 8
  Inc(PInteger(@i)^);
end;

[Sherlock]

Zitat:

Zitat von Uwe Raabe (Beitrag 1517004)

Ohne einen Beleg dafür ist das nur Angstmacherei.

Daher meine knappe Anmerkung in #4: FUD

Sherlock

[Stevie]

Ich korrigiere mal einige Aussagen bezüglich "rückwärts zählende Schleifen".

Sofern die Zählvariable innerhalb des Schleifenrumpfes benutzt wird, fügt der Compiler zusätzlich zu der Zählvariable, welche sich im korrekten Wertebereich bewegt zusätzlich eine Variable ein, die er nutzt, um auf 0 runter zu zählen. Diese wird aber nicht wie etwa von Himitsu skizziert für irgendetwas anderes genutzt als für den Schleifen Code an sich. Interessanterweise passiert dies in dem geposteten Code nicht mal, sondern nur, wenn lower und/oder upper bound variabel sind.

Das auf 0 runter zählen ist eine gängige Optimierung da hierbei nach dem Dekrement direkt ein bedingter Sprungbefehl stehen kann, anstatt zuerst einen Vergleich auf die obere Grenze - je nachdem wie viele Register für den Code gebraucht werden, kann das aber auch eher nachteilig sein, gerade unter 32bit hat man nur eine Handvoll davon.