c++ code optimieren

[Dr. Picasso]

Hi,

ich habe hier ein funktionierendes c++ programm. dieses moechte ich optimieren.

das betriebssystem ist linux. ich schreibe code mit gedit, und ich verwende zum kompilieren nur den befehl 'make' in der console.

generell bin ich fuer jeden hinweis dankbar, der mir hilft das programm schneller zu machen, konkret auf der such bin ich allerdings nach folgender funktionalitaet:

ich wuerde gerne wissen in welchen code-zeilen/routinen das programm am meisten zeit verbringt. (stichwort: profiling)
ram verbrauch ist irrelevant, nur die rechenzeit ist relevant (also cpu time und die zeit irgendwas im ram zu lesen/schreiben)
wenn ich das weiss, kann ich schaun ob ich diese teile des codes optimieren kann.

eine google-suche mit "c++ linux profiler" hat mich nicht weitergebracht, ich brauche da wohl etwas gehhilfe.

was kann ich tun?

 

[ROOT]

wie sieht denn dein makefile aus?
haste schon -O2 / -O3 versucht?

mit profilern hab ich leider noch nie gearbeitet (außer cuda), also ka.

 

[Dr. Picasso]

das makefile habe ich so wie ich es vorgefunden habe, einfach uebernommen. der inhalt ist:

all: main.o
g++ -static main.cpp System.cpp Dish.cpp Player.cpp -o lm.out -lgsl -lgslcblas -lm -O3

 

[Starfire]

kann gedit autocomplete, usage search, call hierarchy, open declaration usw.?
wenn nicht, dann benutz doch eclipse cdt?

dann kannst evtl. aus eclipse kompilieren und auch teilweise debuggen.
code metrics plugins gibts auch ein paar.

hab den internen debugger usw. aber bisher nicht benutzen können, weil das 15jahre alte gewachsene c++ projekt an dem ich rumschraube nur verscriptet kompiliert werden kann x_X
aber code schreiben ist damit schon sehr einfach, weil die autocomplete funktion echt jede methode aus den importierten libs performant anzeigen kann.

hab das ganze auch mit netbeans getestet, der kommt mit viele libs überhaupt nicht klar.
der war 2 stunden lang mit checking external changes beschäftigt.

 

[Dr. Picasso]

ich habe nun um kernroutinen folgenden code gebastelt:

#include <time.h>

clock_t start, end;
double cpu_time_used;

start = clock();
for(int i=0;i<1000000;i++) kernroutine();
end = clock();
cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC;
cout << "time: " << cpu_time_used << endl;

vielleicht unelegant und etwas muehsam, aber leicht umzusetzen und im ergebnis effektiv.
durch reines trial&error habe ich nun einen faktor 10 an speed rausgeholt.

 

[drwilly]

Mh, in Richtung Profiler würde mir spontan Valgrind einfallen.
Habe selbst keine Erfahrungen damit, aber vielleicht hilft dir das ja weiter.

 

[Annihilator]

Wenn sich der Code vernünftig parallelisieren lässt, versuch das.

 

[TealC]

Willy hat Recht. Valgrind ist was Du suchst. Mit der Option callgrind bekommst Du genau aufgeschluesselt, welche Zeile wieviel Zeit verbraucht. Der einzige Nachteil ist, dass der Code massiv langsamer wird. Wenn das ein Problem ist, dann gibt es auch zahlreiche Alternativen, zum Beispiel gprof. Letztenendes tun diese Tools genau das, was Du gerade versuchst, nur in schlau ^^

Ein wenig offtopic: Ich war auch erst in Eclipse, bin dann aber wegen dem Debugger zu Emacs gewechselt. Irgendwie hat es nie funktioniert, irgendwelche Objekte auch nur halbwegs sinnvoll darzustellen.

Ebenfalls offtopic: Schau Dir mal an, wie man Makefiles schreibt. So kompilierst Du ja alles immer komplett von vorne. So schwer ist das nicht und ueber die schnellere Kompilierzeit bist Du bald sehr dankbar.

Parallelisieren ist hier wohl ein wenig übertrieben. Losgelöst davon, sollte man immer zunächst optimieren, bevor man parallelisiert.

 

[Dr. Picasso]

danke, dann werd ich mir mal valgrind anschauen.
dass der code während des testens mit valgrind langsamer wird ist völlig egal, es handelt sich um eine monte-carlo simulation, bei der pro sekunde ~10^5 schritte durchgeführt werden, ein test wird also nach wenigen sekunden schon merken wo die lahmarsch routinen sind.
mit parallelisieren ist da glaub ich nicht so viel zu machen.
das programm kompiliert (alle vorkommenden .cpp) in ~5 sekunden.

 

[ROOT]

monte carlo lässt sich im normalfall hervorragend parallelisieren.

 

[Dr. Picasso]

hier nicht:
es wird ein reaktionsprozess (viele viecher sind in einem topf und interagieren) simuliert. das geschieht aber zeitlich geordnet, es ist also nicht moeglich mehrere reaktionen gleichzeitig durchzufuehren.

im gewissen sinne wird aber bereits parallelisiert:
ich mache mit den ergebnissen statistik, d.h. eine (nicht parallelisierbare) simulation entspricht einer trajektorie von vielen. diese vielen trajektorien erzeuge ich indem ich das programm sehr oft ausfuehre, und zwar gleichzeitig.