[no]DFA, Turbo Pascal und fpc …

[greye]

Hallo zusammen,

ich packe das mal hier rein, weil es mit Lazarus nun wirklich nur ganz am Rande zu tun hat.

Aus Langeweile und als Fingerübung habe ich ein kleines Sinnlos-Progrämmchen geschrieben, das in einer Schleife Berechnungen mit Zufallszahlen durchführt und dabei die Zeit nimmt.
Da es mir nur um die Berechnungen ging und nicht um das Ergebnis, wurde das nicht weiter verarbeitet, hat also den Schleifenkörper nie verlassen.

Der FPC hat ab Optimierungsstufe 3 mittels DFA diese Schleifen einfach wegoptimiert - soweit, so logisch, sie haben ja nix Erkennbares zum Programm beigetragen.

Darüber habe ich mich mit einem Bekannten unterhalten, der früher ein bischen was mit Turbo Pascal gemacht hat und mir sagte, er kenne das nicht, daß der Compiler einen da bevormundet - so seine Worte.

Ich habe jetzt selbst mal geschaut und tatsächlich keinen Hinweis auf diese Art der Optimierung bei TP gefunden, was mich doch wundert, denn gerade zu TP-Zeiten waren Speicher und Rechenzeit noch sehr viel teurer als heute; gerade da hätte ich deshalb erwartet, daß der Compiler Dinge, z.B. Berechnungen, die keinen Mehrwert bringen, weil das Ergebnis nie weiterverarbeitet wird, gar nicht erst in das Kompilat aufnimmt.

Kleine Tests mit TP 7 haben mir gezeigt, daß zumindest die leere Schleife ausgeführt wird, der Schleifenzähler, den ich mir vor und nach der Schleife ausgeben lasse, ist hinterher erhöht.
FPC optimiert mit DFA gleich die ganze Schleife weg, der Schleifenzähler ändert sich nicht.

Lange Rede, kurzer Sinn: Gab es diese Art von Optimierung unter TP wirklich nicht oder bin ich blind und finde dazu nur nichts? Weil, wie geschrieben, gerade das ja wichtig gewesen wäre, um Programme nicht mit nie gebrauchtem Ballast aufzublähen.

Ich bin mal gespannt, was Ihr sagt - vorausgesetzt, Ihr habt verstanden, was ich will …

Liebe Grüße
Michael

[Mathias]

Kleine Tests mit TP 7 haben mir gezeigt, daß zumindest die leere Schleife ausgeführt wird, der Schleifenzähler, den ich mir vor und nach der Schleife ausgeben lasse, ist hinterher erhöht.

An dies mag ich mich noch erinnern. Solch eine Leerschleife konnte man gut als kleines Delay nutzen. Ich hatte dies bei einem Messprogramm. Und als man dann vom 286er auf einen 386er umstieg, musste ich das Programm anpassen.

Unter FPC sollte man die mit $O- auch machen können.

[Warf]

Ich habe jetzt selbst mal geschaut und tatsächlich keinen Hinweis auf diese Art der Optimierung bei TP gefunden, was mich doch wundert, denn gerade zu TP-Zeiten waren Speicher und Rechenzeit noch sehr viel teurer als heute; gerade da hätte ich deshalb erwartet, daß der Compiler Dinge, z.B. Berechnungen, die keinen Mehrwert bringen, weil das Ergebnis nie weiterverarbeitet wird, gar nicht erst in das Kompilat aufnimmt.

Optimierungsmäßig ist bei Compilern extrem viel in den letzten 30 Jahren passiert, der Grund dafür ist das Optimierungsprobleme typischerweise NP Vollständig sind, und selbst analyse von simplen programmen massiv viel Zeit und Speicher frisst. Von daher sind viele dinge insebsondere in der Daten und Kontrollflussanalyse die heute Standard sind, früher gar nicht möglich.
Zusätzlich dazu sind die notwendigen Formalismen für viele Optimierungen auch erst relativ neu. Ich weiß jetzt nicht wie nah FPCs DFA am "puls der zeit" ist, aber wenn man sich anschaut was compiler wie Clang z.B. für C++ machen, wo afaik mittlerweile ein voll funktionsfähiger SAT solver eingebaut wird, wobei viele der Theoreme und algorithmen um solche constraint satisfaction Probleme effizient zu lösen grade mal 10-20 Jahre alt sind.

Darüber habe ich mich mit einem Bekannten unterhalten, der früher ein bischen was mit Turbo Pascal gemacht hat und mir sagte, er kenne das nicht, daß der Compiler einen da bevormundet - so seine Worte.

Naja wenn man diese Einstellung konsequent durchzieht, würde das praktisch gegen fast jede art von aggressiver Optimierung sprechen. Der Grund warum es os aggresive Optimierungen allerdings gibt ist ein simpler: Man möchte das der Entwickler den Code so schreiben können soll das er am einfachsten zu lesen und zu schreiben ist, und der Compiler kümmert sich drum das es effizient ist.

Beispiel, fpc hat die Folgende Optimierung:

Code: Alles auswählen

MyArray += [NewValue];
// Eigentlich equivalent zu
// Erstellen von [NewValue]
SetLength(tmpArray, 1);
tmpArray[0] := NewValue;
// Erstellen von MyArray + TmpArray
SetLength(Tmp2Array, Length(MyArray) + Length(TmpArray));
for i:=0 to High(MyArray) do 
  Tmp2Array[i] := MyArray[i];
for i:=0 to High(TmpArray) do
  Tmp2Array[i + Length(MyArray)] := TmpArray[i];
// Zuweisung zu ergebnis
MyArray := Tmp2Array;
// Wird optimiert zu
SetLength(MyArray, Length(MyArray) + 1);
MyArray[high(MyArray)] := NewValue

Statt der Allokation von zwei temporären arrays in die die Elemente reinkopiert werden, wird stattdessen einfach der Array um eins verlängert. Man hat also optimalen Code, aber statt 2 zeilen um diesen code zu erreichen, mit zwei zeilen in denen man Fehler machen kann, hat man nur eine Zeile, die auch noch dazu extrem simpel ist

[PascalDragon]

Lange Rede, kurzer Sinn: Gab es diese Art von Optimierung unter TP wirklich nicht oder bin ich blind und finde dazu nur nichts? Weil, wie geschrieben, gerade das ja wichtig gewesen wäre, um Programme nicht mit nie gebrauchtem Ballast aufzublähen.

Nein, das gab es bei TP tatsächlich nicht. Das hat auch damit zu tun, dass die DFA Optimierung vergleichsweise teuer ist (deswegen ist sie auch bei FPC erst Teil von -O3) und damit auf den Systemen für die TP gedacht war schlichtweg nicht vernünftig umsetzbar war (unter der Annahme, dass die damaligen Compilerentwickler überhaupt vom Konzept von DFA gehört hatten).