was macht ein optimizer und was nicht?

Hallo,

ich bin eigentlich immer ausgegangen "ein optimizer optimiert, was optimierbar ist"

dafür gibt es mathematische regeln, die dann eben durch so sachen "kann ich es wissen" eingeschränkt werden.

jetzt würd ich aber doch mal gerne nachfragen.

wenn ich z.b sowas hab:

class c
{
private: static unsigned int recog(bool b, unsigned int i) { return b ? i : 0; }
public: static unsigned int f() { return recog(true, 1) | recog(false, 2) ; }
}

eigentlich könnte ein optimizer alle aufrufe nach f() durch eine konstante ersetzen... WENNN, ja wenn...

wenn er wüsste, dass die struktur/die funktion in keinem obj file, das nix von dieser optimierung weiss referenziert wird. (Was ja per default sicherlich nicht der fall ist, weil header files ausgetauscht werden und void* auf diese typen gecastet werden)

gibt es für sowas parameter für den optimizer, die die sichtbarkeit einschränken und sowas dann wegoptimieren?

falls es solche schalter gibt sollte man doch eigentlich davon augehen können, dass höhere sprache (z.b. microsfot clr-sprachen) solche optimierungsmöglichkeiten nutzen?

falls nicht, wäre hier doch bestimmt ein riesiges optimierungspotential?
denn wenn man die datenstruktur und vorhandensein von funktionsaufrufen nicht modifizieren kann ist natürlich das allermeiste, was rein theoretisch an optimierung möglich wäre von vorneherein ausgeschlossen.

gibt es dafür spezielle clr-optimizer?

gruss,
karle

wenn man mal von einer funktionalen sprache ausgeht wird das ganze erst richtig interessant....

(blos wer schreibt so nen optimizer? hehe, ich bestimmt nicht. macht mal...

Bashar

karle_at_nfr schrieb:

class c
{
private: static unsigned int recog(bool b, unsigned int i) { return b ? i : 0; }
public: static unsigned int f() { return recog(true, 1) | recog(false, 2) ; }
}
eigentlich könnte ein optimizer alle aufrufe nach f() durch eine konstante ersetzen... WENNN, ja wenn...

wenn er wüsste, dass die struktur/die funktion in keinem obj file, das nix von dieser optimierung weiss referenziert wird.

Was ändert das? f ist inline, also ist der Körper von f an jeder Aufrufstelle bekannt. Ich denk mir mal, er wird zuerst innerhalb von f optimieren (zu return $IRGENDEINEKONSTANTE; ) und das dann überall inlinen. Wenn er's mal nicht inlinen kann aus was für Gründen auch immer würde dort halt ein echter Aufruf stehen und der Körper von f auch einmal "out of line" generiert werden.

Oder hab ich das Problem nicht verstanden?

doch hast du.

ich hab grad nicht mehr drangedacht, das da die inline geschichte mitspielt. (c++ ist schon ne weile her)

dann hätte ich noch folgende fragen:

1. Was ist wenn die funktion nicht inline ist? gibt es optimizer, die ein fertig gelinktes executable auf byte-code ebene auseinanderpflücken und sowas selbst für nicht-inlienes wegoptimieren?

2. ich bin davon ausgegangen, dass höhere sprachen normalerweise über den umweg c in maschinencode kompiliert werden. (hat mir mal jemand erzählt, der davon wirklich ne ahnung haben könnte) ist das so? (ich bin durch eine microsoft-doku für clr vermeintlich darin bestätigt worden, aber hab nochmal nachgeschaut, das ist nicht sicher)

Bashar

karle_at_nfr schrieb:

1. Was ist wenn die funktion nicht inline ist? gibt es optimizer, die ein fertig gelinktes executable auf byte-code ebene auseinanderpflücken und sowas selbst für nicht-inlienes wegoptimieren?

Stichwort Link Time Code Generation.

2. ich bin davon ausgegangen, dass höhere sprachen normalerweise über den umweg c in maschinencode kompiliert werden. (hat mir mal jemand erzählt, der davon wirklich ne ahnung haben könnte) ist das so?

C ist eine ganz brauchbare Zielsprache mit dem Vorteil, sehr portabel zu sein (im Sinne von: auf vielen Architekturen verfügbar), hat also einige Vorteile gerade für Sprachen in einem experimentellen Stadium. Aber ob es wirklich der Normalfall ist? Es gibt auch C--, oder man benutzt einen fertigen Codegenerator. Aber lies es lieber von den Experten: http://lambda-the-ultimate.org/node/3631
Das ist überhaupt eine sehr interessante Seite, wenn du dich für Compilerbau und Programmiersprachendesign interessierst.