Performance richtig messen
-
maximAL schrieb:
Ausserdem muessen die Funktionen schon sehr klein sein, sonst laesst sich auch nicht nachvollziehen was in einer Funktion jetzt teuer ist.
Das kann man sich auch zeilenweise anzeigen lassen, nicht nur funktionsweise.
-
Ich frage mich ob es wirklich valide ist die performance über zeitmessung zu vergleichen? Wären da nicht MIPS oder dergleichen wesentlich aussagekräftiger?
Wenn du ordentlich misst, nicht. Volkard hat hier eine Methode plakatiert, die ziemlich zuverlässige Ergebnisse produziert.
Ein Profiler ist aber i.d.R. nützlicher, da er die genauen Anweisungen aufzeigt, die viel Zeit totschlagen, sowie die relevanten Verhältnisse. Das, kombiniert mit ordentlicher Zeitmessung, dürfte dich weiterbringen.Problematisch nur, dass "professionelle Profiler" (wie Intel V-Tune) gleich ein Vermoegen kosten.
Reicht Callgrind nicht für den Anfang?
-
Der Profiler von AMD heisst CodeAnalyst.
Funktioniert grundsätzlich auch mit Intel CPUs, aber da nur im "sampling" mode. D.h. er nimmt einfach ein Sample pro Millisekunde. Für manche Anwendungen ist das genug, gerade wenn man sie laaaaaaange laufen lässt. Für Anwendungen die etliche verstreute Hot-Spots haben und wo man nur kurz (sagen wir mal < 1 Minute) profilen will/kann ist er aber nach meiner Erfahrung weniger interessant.Den von VS 2015 hab' ich noch nicht ausprobiert. Klingt aber interessant.
-
wenn dein Programm wirklich langsam ist (mehere sekunden), reicht es auch schon oft, dich mit dem debugger zu attachen und pause zu drücken. wenn du nach ein paar mal pause drücken immer den selben callstack hast, ist das zu 98% die stelle die optimiert werden muss. Das ganze natürlich im release build.
-
Der Profiler von AMD heisst CodeAnalyst.
Er hieß so, jetzt heißt er CodeXL.
-
Danke für den Hinweis!
Laut Wiki ist CodeXL nicht nur ein neuer Name sondern ein anderes Tool, welches CodeAnalyst ersetzt.
Hmmm...
Sollte ich mir dann vielleicht auch mal angucken -- vielleicht kann der ja mehr als der CodeAnalyst (speziell mit Intel CPUs :D, obwohl das ja schon irgendwie pervers ist).
-
hat vor allem GPU profiling moeglichkeiten, z.b. kannst du shader (glsl und hlsl) fuer jede hardware generation kompilieren und statistiken ausgeben (z.B. VGPR count).
sollte opencl unterstuetzen (wenn du eine AMD karte hast).cpu teil ist nicht viel anders als code analyst.
-
Beim CPU Profiling hat mir VS viel besser gefallen, als CodeXL. Allerdings beides mit Sampling. Mit Instrumentation hab ich das in VS bisher nicht auf die Reihe bekommen, vielleicht sind die Dlls dem einfach zu groß, keine Ahnung. Aber Sampling hat bei mir bisher immer gut genug funktioniert.
-
Wenn schnell genug gesampelt wird wird sampling wohl OK sein.
1ms is aber ne kleine Ewigkeit. Damit hab ich bisher keine guten Ergebnisse bekommen. VTune (mit Instrumentation) war da viel viel cooler.
Vor allem weil man da wirklich jede "Edge" im Ergebnis drin hatte.
-
ich finde sampling besser, weil es weniger intrusive ist. wirklich optimierter code kann durch instrumentation sehr verfaelscht werden, mit sampling eher weniger, weil bis zum moment des samples die ausfuehrung lange genug unverfaelscht war und dann erst nach dem sample moment ein wenig verzerrt ist, sich aber schnell normalisiert.
wenn es wirklich sehr genau sein muss, nehm ich lieber static code analyser oder simulatoren (z.B. Intel SDE).
-
Ich hab gestern übrigens gelesen, dass die Samping Rate bei VS per Default sogar nur bei 0.01 Sekunden liegt. Kann ich fast nicht glauben, weil die Ergebnisse bisher meistens ziemlich gut waren. Hat schon mal jemand probiert, die wesentlich höher einzustellen, z.B. 0.0001 Sekunden?
