Compileroptimierungen

[berniebutt]

Icematix schrieb:

Ich behaupte, ein Nicht-Experte optimiert auf jeden Fall schlechter als ein Compiler.

Volle Zustimmung. Also ist die Frage Quatsch, man kann seine Mühe besser in der Optimierung seines eigenen Code verwenden!

[Icematix]

Zum Beispiel Variablen/Objekte erst deklarieren, wenn sie gebraucht werden, hilft dem Compiler ziemlich.
Dann eben wann immer Möglich Referenzen auf Objekte arbeiten anstatt sie zu kopieren etc

Gibt es eigentlich gute Online-Literatur zu dem Thema Quellcode-Optimierung?

[Gast]

Icematix schrieb:

Zum Beispiel Variablen/Objekte erst deklarieren, wenn sie gebraucht werden, hilft dem Compiler ziemlich.
Dann eben wann immer Möglich Referenzen auf Objekte arbeiten anstatt sie zu kopieren etc

const verwenden, wo sinnvoll und möglich. Das ermöglicht dem compiler den Code unter bestimmten Bedingungen umzustellen, so dass er schneller wird. z.B. durch das Zusammenfassen von Gleitkommaoperationen, um eine bessere Auslastung der Vektoreinheit (SSE, Altivec) des Prozessors zu erreichen.

Wenn es Möglich ist, sollte man auf optimierte Bibliotheken, wie BLAS oder liboil verwenden. Da hat sich schon jemand die Arbeit gemacht, bestimmte Operationen zu optimieren. Wenn dann noch Operationen übrig bleiben, die nicht von diesen Bibliotheken abgedeckt sind, kann man (wenn man es denn kann) noch mit Assembler optimieren.

ABER: Bevor man das macht. Auf jeden Fall den Code erstmal korrekt haben. Und dann erstmal ein paar Opimierungsparameter vom Compiler durchprobieren!

[ef]

ProgChild schrieb:

Icematix schrieb:

Zum Beispiel Variablen/Objekte erst deklarieren, wenn sie gebraucht werden, hilft dem Compiler ziemlich.
Dann eben wann immer Möglich Referenzen auf Objekte arbeiten anstatt sie zu kopieren etc

const verwenden, wo sinnvoll und möglich. Das ermöglicht dem compiler den Code unter bestimmten Bedingungen umzustellen, so dass er schneller wird.

http://www.gotw.ca/gotw/081.htm

It's a common belief that const-correctness helps compilers generate tighter code. Const is indeed a Good Thing, but the point of this issue of GotW is that const is mainly for humans, rather than for compilers and optimizers.

[berniebutt]

Icematix schrieb:

Gibt es eigentlich gute Online-Literatur zu dem Thema Quellcode-Optimierung?

Weiss nicht, habe noch nicht gesucht. Das Thema ist aber so alt wie die Programmierung selbst. Ein paar Regeln sind schon genannt. Man kann entweder nach Laufzeit oder nach Speicherbedarf optimieren. Nach Speicherbedarf spielt heute meist keine grosse Rolle mehr. Noch ein paar Regeln zur Laufzeit hinzu:
- Zeigerarithmetik nutzen
- Multiplikation ist schneller als pow(). Beispiel a*a statt pow(a,2)
- Mehrdimensionale Arrays in der Reihenfolge der Speicherung bearbeiten
- Grössere Datentypen wie long und double nur verwenden, wenn sie tatsächlich nötig sind
- In Schleifen redundanten Code vermeiden, also nicht mehrfach dasselbe berechnen
Alle Möglichkeiten zur Optimierung lohnen aber nur, wenn dabei signifikante Unterschiede in der Laufzeit heraus kommen. Drei Tage am Code pfeilen für vielleicht 10 Millisekunden ist unsinnig.

[löschard]

Th69 schrieb:

Aber bitte keine "premature optimization"!!!

wo ist eigentlich volkard?

[Superlexx]

das Beste, worüber ich die letzte Zeit gestöbert bin, kommt von fefe (CCC), z.B.

http://www.fefe.de/know-your-compiler.pdf

[volksard]

Superlexx schrieb:

das Beste, worüber ich die letzte Zeit gestöbert bin, kommt von fefe (CCC), z.B.

http://www.fefe.de/know-your-compiler.pdf

Das beste da sind die letzten 2 Sätze

If you do an optimization, test it on real world data.
If it’s not drastically faster but makes the code less readable: undo it.

[DocShoe]

Th69 schrieb:

Aber bitte keine "premature optimization"!!!

Das war mein Part

Ansonsten kann ich dir nur folgende Tipps geben:
- Auswahl des passenden Algorithmus
- Parameterübergabe call-by-reference statt call-by-value
- Ausnutzen von Spracheigenschaften wie return value optimization
- Benutzen von Funktoren statt Funktionspointern in Schleifendurchläufen

Was Berniebutt geschrieben hat stimmt auch nur teilweise, für Ganzkommazahlen solltest du den Datentyp benutzen, der genau der Breite des CPU Datenbus entspricht. Bei allen anderen Datentypen muss der Prozessor halbe/viertel/doppelte Datenwörter schreiben, was zusätzliches Maskieren bedeuten kann
Die FPU kann mit double schneller rechnen als mit float (vermutlich aus den gleichen Gründen wie oben), daher für Fliesskommaoperationen lieber double als float benutzen. Aber das ist alles CPU spezifisch und kann sich von Plattform zu Plattform ändern.

[player4245]

DocShoe schrieb:

- Parameterübergabe call-by-reference statt call-by-value

Ich mag solche allgemein formulierten Regeln nicht besonders. Auf nem 32-Bit system z.B. ist es völlig schnuppe ob du einen Zeiger oder gleich den integer selbst übergibst. Aber das nur als Beispiel.

[asdfasd]

In dem Artikel heißt es:

Use mul instead of shift: 5 cycles penalty.
Conditional branch mispredicted: 10 cycles.
Cache Miss to main memory: 250 cycles.

Das erste verstehe ich. Aber was will er mit den anderen zwei Sätzen aussagen?

[SeppJ]

asdfasd schrieb:

In dem Artikel heißt es:

Use mul instead of shift: 5 cycles penalty.
Conditional branch mispredicted: 10 cycles.
Cache Miss to main memory: 250 cycles.

Das erste verstehe ich. Aber was will er mit den anderen zwei Sätzen aussagen?

Branch predictor: Es ist günstiger, wenn if-Abfragen in Schleifen möglichst oft hintereinander das gleiche Ergebnis haben.

Cache miss: Kann zwei Ursachen haben:
Zu große Codesegmente in einer Schleife (das ist die dunkle Seite von inline).
Oder zu wildes Herumspringen im Arbeitspeicher. Es ist günstiger, Speicheradressen möglichst oft nacheinander zu benutzen. Und es ist günstiger Speicheradressen möglichst in durchgehender (oder zumindest vorhersehbarer) Reihenfolge zu benutzen.

[Superlexx]

Und noch ein Vortrag von ihm, diesmal ausführlicher:

http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf

[dfghfjfd]

berniebutt schrieb:

- Zeigerarithmetik nutzen

Da scheiden sich die Geister. Zeiger können den Compiler am optimieren hindern, da er den Wert des zeigers nicht einfach in eine temporäre Variable stecken kann und somit das Referenzieren einsparen kann. Denn es könnte ja sein, dass ein anderer Zeiger den Wert, auf den der Zeiger zeigt, in der Zwischenzeit ändert. Daher empfiehlt der "Software Optimization Guide for AMD64 Processors" zB das Benutzen von Indexoperationen (Wenn es um array Zugriff geht)