Compileroptimierungen
-
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 etcconstverwenden, 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.
-
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.
-
Th69 schrieb:
Aber bitte keine "premature optimization"!!!
wo ist eigentlich volkard?
-
das Beste, worüber ich die letzte Zeit gestöbert bin, kommt von fefe (CCC), z.B.
-
Superlexx schrieb:
das Beste, worüber ich die letzte Zeit gestöbert bin, kommt von fefe (CCC), z.B.
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.
-
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äufenWas 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.
-
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.
-
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?
-
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.
-
Und noch ein Vortrag von ihm, diesmal ausführlicher:
http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf
-
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)
