Performance Optimieren -> Werkzeuge od. Tricks?
-
Sowas kannst du mit einem Profiler machen, der die benötigten Taktschritte zählt und nicht die Zeit. Das sollten eigentlich die meisten Profiler auch können. Dann ist dein Ergebnis vollkommen unabhängig von der Systemauslastung.
Wenn du dann noch zeigen willst, wie gut dein Code ist (sofern er es ist), kannst du dann noch die Flops/Taktschritt deines Programms ausrechnen und mit dem theoretischen Maximum deiner Architektur vergleichen. Hochoptimierte Numerikprogramme machen diese Angabe oft um zu zeigen wie effizient sie mit der Rechenzeit umgehen, aber mit denen wirst du dich kaum messen können.
-
Wenn du dann noch zeigen willst, wie gut dein Code ist (sofern er es ist), kannst du dann noch die Flops/Taktschritt deines Programms ausrechnen und mit dem theoretischen Maximum deiner Architektur vergleichen. Hochoptimierte Numerikprogramme machen diese Angabe oft um zu zeigen wie effizient sie mit der Rechenzeit umgehen, aber mit denen wirst du dich kaum messen können.
Sehr interessant - danke für den Hinweis. Wie berechne ich mir denn die Flops/Taktschritt in meinem Programm? Ginge das auch über die Profiler?
-
Bleistift schrieb:
Sehr interessant - danke für den Hinweis. Wie berechne ich mir denn die Flops/Taktschritt in meinem Programm? Ginge das auch über die Profiler?
Die paar Male die ich das gemacht habe, habe ich das über einen Profiler gemacht. Das war allerdings ein Profiler der speziell für eben jenen Rechner (bzw. jene Rechnerarchitektur) gemacht war. Ich weiß nicht, ob normale Profiler das auch können, weil ich die nicht so häufig verwende. Ich muss die Frage deshalb an die Allgemeinheit weitergeben.
-
drakon schrieb:
Geht auch mit Intel CPU's. Und du kannst dort genau jede Funktion anschauen, wie es im Verhältnis aussieht. Und je nach Einstellung auch die Zeit.
Der AMD Code Analyst geht zwar mit Intel CPUs, allerdings ist die Funktion gröbstens eingeschränkt (nur Interval-Sampler mit dem kürzesten Interval = 1ms -> ein schlechter Scherz).
-
hustbaer schrieb:
drakon schrieb:
Geht auch mit Intel CPU's. Und du kannst dort genau jede Funktion anschauen, wie es im Verhältnis aussieht. Und je nach Einstellung auch die Zeit.
Der AMD Code Analyst geht zwar mit Intel CPUs, allerdings ist die Funktion gröbstens eingeschränkt (nur Interval-Sampler mit dem kürzesten Interval = 1ms -> ein schlechter Scherz).
Welchen Profiler benutzt man dann für Intel CPUs bzw gibt es nicht einfach einen, der auf Intels und AMDs läuft?
-
Ich kenne keinen Profiler der gratis wäre und auf Intel CPUs gut läuft. Leider.
Nicht-gratis Teile gibt's, z.B. den VTune von Intel (wobei ich aber wieder nicht weiss wie gut der wieder mit AMD CPUs funktioniert).Wer andere kennt bitte ergänzen.
(Die GNU Toolchain müsste auch was haben, wobei die vermutlich dann nur mit GNU Compilaten funktioniert?)
-
Für die GNU Toolchain kenne ich gprof bzw. callgrind mit dem Interface kcachegrind. Und genau hier würde mich interessieren wie genau die sind...
Hat jemand Erfahrungswerte?
-
Was wäre mit einem Monitoring? Wäre wohl die Art über RDTSC Funktionen zu klammern und clocks zu zählen oder?
Oder ist Profiling die sauberste Art bottlenecks zu finden?
-
Profiling ist IMO die praktikabelste Art Hot-Spots zu finden.
Man muss am Code nix ändern, und man bekommt - je nach Profiler - viel mehr als nur die Info wieviel Zeit in Funktion XYZ verbracht wurde.VTune z.B. kann einem einen schönen Call-Graph erstellen, wo man genau sieht welche Funktion welche anderen Funktionen wie oft aufgerufen hat, wie viel Zeit dabei draufgeganen ist etc. Dieser lässt sich dann auch rückwärts navigieren, d.h. wenn ich weiss Funktion X ist mein Hot-Spot, dann kann ich zurückgehen, und sehe vielleicht dass 2% der Aufrufe von Funktion A kommen, 5% der Aufrufe von Funktion B, und der Rest von Funktion C. Das ist sehr oft wichtig, da oft die Funktion "am Ende des Callstacks" (X) nichtmehr sinnvoll optimiert werden kann, dafür Funktionen "davor" (A, B, C) leichter so umgestellt werden können dass sie die betreffende Funktion (X) nichtmehr so oft aufrufen.
Weiters können manche Profiler noch andere Dinge "messen", z.B. wie oft man Cache-Misses an bestimmten Programmstellen produziert, wie oft man die Pipeline stallt und vieles mehr.
----
Manuell Funktionen mit RDTSC zu spicken kann Sinn machen wenn man nur ein sehr kleines Stück Code "ausmessen" will, bei grossen Projekten ist sowas aber absolut undurchführbar. (Es sei denn man lässt diese Änderung am Code automatisch durch irgendein Tool durchführen -- wobei ich so ein Tool dann schonwieder als Profiler bezeichnen würde)
-
Danke für den Beitrag. Nur ich glaube Vtune ist wohl nicht kostenlos...kann das sein? Zumindest lese ich es überall dass es kostenpflichtig ist...
-
Wie sieht es eigentlich mit parallelem Profiling aus? Gäbe es da überhaupt eine Möglichkeit? Oder liegt hier das Problem genau da wo es beim parallelen Debugging liegt?
-
Leider richtig, VTune kostet ganz dick $$$
Dass der nicht kostenlos ist hab ich aber auch schon ganz klar geschrieben, hättest du halt lesen müssen.
(Davon abgesehen bekommt das jeder der nicht total dämlich und/oder total faul ist in 5 Minuten selbst raus -- Zugang zum Internet vorausgesetzt)Aber WTF meinst du mit "parallelem profiling"? Jeder gute Profiler kann Programme mit mehreren Threads profilen, auch wenn diese auf mehreren Cores laufen. Gewisse spezielle Dinge sind natürlich u.U. nicht einfach zu finden, Sachen wie Priority Inversion, Kämpfe darum "wem welche Cache Line gehört" etc.
Gewisse Hilfestellung bekommt man von einigen guten Profilern allerdings sogar bei diesen Sachen.----
BTW: wer einen Profiler für "Wintel" kennt der gratis ist und auch nur halbwegs gut (eben nicht so ein Ranz wie AMD Code-Analyse im Zusammenspiel mit ner Intel CPU): daran wäre ich auch sehr interessiert.
-
(Davon abgesehen bekommt das jeder der nicht total dämlich und/oder total faul ist in 5 Minuten selbst raus -- Zugang zum Internet vorausgesetzt)
Richtig. Habe ich auch. Doch mir ist das im Moment so wichtig dass ich da gern eine zweite Meinung einholen wollte um sicher zu gehen dass es wirklich kostenpflichtig ist. Nächstes mal sage ich das dazu - danke.
Mit parallelem Profiling meine ich folgendes:
Ich habe eine Anwendung die parallel läuft (MPI und z.B. auf 128 CPU's) wovon jede CPU einen Teil des Gesamtproblems löst. Die CPU's kommunizieren auch untereinander - tauschen Daten aus).
Und diese Anwendung will ich jetzt profilen.
-
Bleistift schrieb:
(Davon abgesehen bekommt das jeder der nicht total dämlich und/oder total faul ist in 5 Minuten selbst raus -- Zugang zum Internet vorausgesetzt)
Richtig. Habe ich auch. Doch mir ist das im Moment so wichtig dass ich da gern eine zweite Meinung einholen wollte um sicher zu gehen dass es wirklich kostenpflichtig ist. Nächstes mal sage ich das dazu - danke.
Achso. Hm. OK.
Sorry für die unfreundlichen Worte im übrigen :xmas1:Mit parallelem Profiling meine ich folgendes:
Ich habe eine Anwendung die parallel läuft (MPI und z.B. auf 128 CPU's) wovon jede CPU einen Teil des Gesamtproblems löst. Die CPU's kommunizieren auch untereinander - tauschen Daten aus).
Und diese Anwendung will ich jetzt profilen.Ah, OK, verstehe. Also was SMP angeht wie gesagt: relativ einfach, das kann jeder gute Debugger/Profiler. Wenns mal "grösser" wird als SMP... das fällt dann in einen Bereich wo ich keine Erfahrung und auch kaum "hören-sagen" Wissen habe.
Eventuell könnte man einzelne Nodes mit einem ganz normalen Profiler profilen. Wenns um den Code geht der für die Verteilung auf die Nodes zuständig ist, und ob das so läuft wie man möchte, dann wird das vermutlich aber nichts bringen. Denke aber da sollte das Toolkit/OS/... welches man verwendet um sein Programm auf einem Cluster zu verteilen irgendwelche Tools mitbringen die einem da helfen können. Oder stelle ich mir das jetzt zu "rosig" vor?
