proggen.org

EDIT by Xin: von Celsius -> Fahrenheit-Programm abgetrennt

Zur Info:

• -Wall Schalte alle Warnungen an. Es ist guter Stil so zu programmieren, dass trotzdem keine Warnungen auftauchen.
• -O3 Höchste Optimierungsstufe. Der g++ garantiert hier glaube ich nimmer, dass der Code das macht was er soll. Dafür ist schnell. Hab ich beim Entwickeln immer aus.
• -o <name> so heißt dein Programm danach.
• -g Debug-Symbols einschalten. Hat man euch beigebracht, was ein Debugger ist?

Ich empfehle auf jeden Fall ein gutes Einsteigerbuch anzuschaffen. Meiner Meinung nach gibt esim Netz (noch) kein Tutorial, dass ein Buch ersetzen könnte.

Gute Bücher sind: "Der C++-Programmierer", "C++ Einführung und professionelle Programmierung", "C++ Lernen und Professionell anwenden",
und das neue von Bjarne, dem Vater von C++: http://www2.research.att.com/~bs/programming.html

Bitte nichts von Galileo Computing. Diese parallel zu deinem Kurs durchzuarbeiten wird dir im Endeffekt ne Menge Zeit sparen.

Ansonsten: Wer nicht fragt, bleibt dumm.

Panke hat geschrieben:Zur Info:

• -Wall Schalte alle Warnungen an. Es ist guter Stil so zu programmieren, dass trotzdem keine Warnungen auftauchen.
• -O3 Höchste Optimierungsstufe. Der g++ garantiert hier glaube ich nimmer, dass der Code das macht was er soll. Dafür ist schnell. Hab ich beim Entwickeln immer aus.

Kleine Anmerkung: Optimierungen sollte man immer anschalten, wenn man entwickelt, da dann der Code noch genauer untersucht wird und noch mehr Warnungen ausgespuckt werden, falls vorhanden (z.B. nicht benutzte Variablen oder Variablen, die benutzt werden bevor sie initialisiert werden, werden nur mit Optimierungen verwarnt).

Das wusst ich gar nicht. Gut zu wissen. Andererseits ist das Verhalten im Debugger bei -O3 nicht immer 100% einsichtig.

Naja, -O2 dürfte eigentlich ausreichen. Weitere Optimierungen kann man dann für die Release-Version vornehmen - natürlich testen ob sich das Programm immernoch genauso verhält

Panke hat geschrieben:Das wusst ich gar nicht. Gut zu wissen. Andererseits ist das Verhalten im Debugger bei -O3 nicht immer 100% einsichtig.

Nicht nur das, wie ich gesehen habe killt -O3 auch Optimierungen! Durch das inlinen von Funktionen wird der Code größer und wird deshalb langsamer in den L1/L2 (?) Cache geladen. Deswegen sollte man immer, wenn man -O3 verwendet auch -fno-inline mitgeben.

fat-lobyte hat geschrieben:

Panke hat geschrieben:Das wusst ich gar nicht. Gut zu wissen. Andererseits ist das Verhalten im Debugger bei -O3 nicht immer 100% einsichtig.

Nicht nur das, wie ich gesehen habe killt -O3 auch Optimierungen! Durch das inlinen von Funktionen wird der Code größer und wird deshalb langsamer in den L1/L2 (?) Cache geladen. Deswegen sollte man immer, wenn man -O3 verwendet auch -fno-inline mitgeben.

Aus dem Thread lerne ich gerade auch einiges... ^^

Vielleicht könnte man das auch mal in einer Wiki-Seite zusammenfassen?

Der Visual Studio 2010 Compiler sagt mir, O1 minimiert die Größe der ausgegebenen Datei so gut es geht und O2 maximiert die Geschwindigkeit so gut es geht. O3 hat man gar nicht implementiert, dafür gibt es Ox, was beides vereinen soll. Bin mir aber nicht sicher, wie sehr man das auf g++ oder minGW Compiler übertragen kann/darf.

MoonGuy hat geschrieben:Der Visual Studio 2010 Compiler sagt mir, O1 minimiert die Größe der ausgegebenen Datei so gut es geht und O2 maximiert die Geschwindigkeit so gut es geht. O3 hat man gar nicht implementiert, dafür gibt es Ox, was beides vereinen soll. Bin mir aber nicht sicher, wie sehr man das auf g++ oder minGW Compiler übertragen kann/darf.

-O0 = keine Optimierungen, schnellerer Compile

-Os = möglichst kleines Binary, wie -O2 ohne Optimierungen, die die Größe erhöhen würden

-O/-O1 = weniger Codegröße, schnellere Ausführung: -fauto-inc-dec -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-small-functions -fipa-pure-const -fipa-reference -fmerge-constants -fsplit-wide-types -ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-sra -ftree-ter -funit-at-a-time

-O2 = stärkeres Optimieren, aber kein loop unrolling oder function inlining; wie -O1, plus: -fthread-jumps -falign-functions -falign-jumps -falign-loops -falign-labels -fcaller-saves -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fexpensive-optimizations -fgcse -fgcse-lm -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-interblock -fsched-spec -fschedule-insns -fschedule-insns2 -fstrict-aliasing -fstrict-overflow -ftree-pre -ftree-vrp

-O3 = wie -O2, plus: -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize

fat-lobyte hat geschrieben:Deswegen sollte man immer, wenn man -O3 verwendet auch -fno-inline mitgeben.

Warum? Dann kann man auch gleich -O2 nehmen..

oenone hat geschrieben:

fat-lobyte hat geschrieben:Deswegen sollte man immer, wenn man -O3 verwendet auch -fno-inline mitgeben.

Warum? Dann kann man auch gleich -O2 nehmen..

Richtig. Das sollte man auch machen. Ich habe für ein kleines Projekt mal nachgemessen, was -O3 und -O2 tut. Mit -O2 wars ungefähr 2-3 mal schneller, mit -O3 wars gleich wie unoptimiert. Mit -O3 und -fno-inline ähnlich wie mit -O2.

Deswegen: BITTE BITTE BITTE finger von -O3 lassen, da es gefährlich ist (in dem Sinne dass es subtile Bugs einbauen kann) und manchmal der Performancegewinn nicht vorhanden ist.
Wenn ihr die Zeit und die Instrumente habt um den Geschwindigkeitsgewinn akkurat zu messen, dann kann man experimentieren. Aber einfach *irgend*ein Optimierungs-flag dazugeben hallte ich für nicht angebracht.