Verschiedene Aufrufe -> Unerklärlicher Mehraufwand

drakon

CodeAnalyst von AMD einfach nicht klar komme

Ich habe den mehr oder wenig von Anfang an rein intuitiv bedienen können.
OK. Einen Haufen Funktionalität habe ich bis jetzt nicht gebraucht, aber die Engpässe + den Code dazu habe ich relativ schnell rausgefunden, wie ich die bekommen kann. (gibt glaube ich auch irgendwo ein paar Tuts dazu..)

Tachyon

Dravere schrieb:

Hat sich erledigt. Konnte es ... lösen ... oder ... naja, dieses Problem ist weg, dafür kamen sich 4 weitere Seltsamheiten zu Tage. Die ich zwar nicht begreife oder nicht ganz, aber nicht weiter wichtig sind und umgangen werden können.

Ich brauch einen vernünftigen Profiler ...

Grüssli

Was hast Du denn so alles in Deiner Document-Kasse drin? Nicht zufällig noch einen ganzen Satz an Strings oder gar Streams, die wieder mit zerstört werden? Das kannst Du nämlich im Dtor so nicht messen.

Document::~Document()
  {
    std::clock_t start = std::clock();

    // ...

    std::clock_t end = std::clock();

    // Speicherung/Ausgabe von (end - start) = 146ms
  } //!!!! hier werden noch alle möglichen nichtrivialen Objekte von Document zerstört !!!!

Dravere

@drakon,
Dann zeig mir diese Tutorials. Ich bin irgendwie zu blöd für das Ding oder bringe zu wenig Geduld mit...

Tachyon schrieb:

Was hast Du denn so alles in Deiner Document-Kasse drin? Nicht zufällig noch einen ganzen Satz an Strings oder gar Streams, die wieder mit zerstört werden? Das kannst Du nämlich im Dtor so nicht messen.

Ne ne, es sind nur 3 Variablen darin:

NodeList_t m_nodeList;         // Wird innert 0ms aufgeräumt
Declaration* m_declaration;    // Wird gemessen, da per delete gelöscht.
DocumentHandler* m_docHandler; // Wird gemessen, da per delete gelöscht.

Aber wie ich schon sagte, das Problem hat sich erledigt. Hatte die Ausgabe der Ergebnisse zu früh angesetzt, wodurch eine Messung unterschlagen wurde.

Inzwischen kamen ganz andere Probleme auf. Wenn ich zum Beispiel zwei Codestücke vergleichen wollte (C1, C2), dann kam es ganz drauf an, in welcher Reihenfolge ich sie ausführte. C2 ging immer gleich lange, aber C1 ging deutlich schneller, wenn es vor C2 ausgeführt wurde, bzw. deutlich langsamer wenn danach. Dabei gibt es keinen Zusammenhang zwischen C1 und C2.

Und dann hab ich noch ein Problem entdeckt. Wenn ich die Klasse, welche sich in einer statischen Bibliothek befindet, selber im eigenen Programm implementiere und somit nicht die genau gleiche Klasse aus der Bibliothek verwende, dann läuft mein Testcode um satte 150ms schneller. Statt 200ms braucht es nur 50ms. Aber wahrscheinlich hat es etwas damit zu tun, dass der Compiler schlechter optimieren kann, wenn er die Klasse aus einer statischen Bibliothek beziehen muss, als wenn sie im eigenen Code vorhanden ist.

Naja, inzwischen weiss ich - oder glaube es zu wissen - , dass meine Bibliothek ein wenig länger braucht um ein XML Document zu erstellen, dafür deutlich schneller das Document wieder aufräumt, als TinyXML

Grüssli

drakon

http://developer.amd.com/documentation/articles/pages/1212200690.aspx

Wenn ich mich recht erinnere, habe ich da ein wenig reingelesen und dann ging es.
(Obwohl ich irgendwie stark vermute, dass mir der Text nicht sehr viel gebracht hat und ich darum einfach selber ein wenig rumprobiert habe..)

Dravere

drakon schrieb:

http://developer.amd.com/documentation/articles/pages/1212200690.aspx

Wenn ich mich recht erinnere, habe ich da ein wenig reingelesen und dann ging es.
(Obwohl ich irgendwie stark vermute, dass mir der Text nicht sehr viel gebracht hat und ich darum einfach selber ein wenig rumprobiert habe..)

Hab den Link mal gespeichert. Allerdings, laut dem Titel, ist der Artikel für AMD Prozessoren. Aber hoffentlich werden auch Infos darin zu finden sein, welche ich für meine Intel-CPU verwenden kann.
Naja, lesen tue ich es erst später, habe aktuelle noch ein paar andere Dinge zu erledigen

Danke für den Link.

Grüssli

Meine Empfehlung:
http://www.glowcode.com

hustbaer

Also CodeAnalyst ist schon OK. Blöderweise kann man den mit Intel-CPUs ziemlich vergessen (wundert mich nicht, aber schade halt). Läuft zwar, aber ein Sample-Intervall von 1ms ist ... IMO einfach lächerlich.

Dravere

Redhead schrieb:

Meine Empfehlung:
http://www.glowcode.com

Nette Empfehlung ... nur kostet das Dinge genauso viel, wie andere Profiler. Und ich will mir so einen Profiler nicht leisten. 500$/€ ausgeben für etwas, was ich nur äusserst selten brauche und derzeit sowieso nicht für ein Produkt, aus welchem ich Geld beziehe. Sowas wäre ein wenig krank ...
Wenn ich dann mal soweit bin, denke ich aber eher, dass ich mir AQTime kaufe oder wenn ich das Geld aufbringen kann (aktuell 2'700€), dann vielleicht DevPartner Studio.

Da ist es schon irgendwie verlockend, die Dinger zu cracken ... bin doch nur ein mehr oder weniger Hobbyprogrammierer, der gerne ein wenig was lernen möchte in dem Bereich ^^"
Und nein, ich crack die Dinger nicht und bin auch nicht dran interessiert. Bevor jemand ausruft

Grüssli

Tachyon

Was ist denn mit Valgrind? Das hat doch auch einen Profiler.

Fellhuhn

gprof?

Dravere

Tachyon schrieb:

Was ist denn mit Valgrind? Das hat doch auch einen Profiler.

Aber Valgrind ist nur Linux, soweit ich weiss. Und ich arbeite nunmal auf Windows mit Visual Studio

Fellhuhn schrieb:

gprof?

gprof geht soweit ich weiss nur mit dem gcc, bzw. g++. Ich arbeite aber, wie gesagt, mit Visual Studio.

Grüssli

Tachyon

Dravere schrieb:

Tachyon schrieb:

Was ist denn mit Valgrind? Das hat doch auch einen Profiler.

Aber Valgrind ist nur Linux, soweit ich weiss. Und ich arbeite nunmal auf Windows mit Visual Studio

Fellhuhn schrieb:

gprof?

gprof geht soweit ich weiss nur mit dem gcc, bzw. g++. Ich arbeite aber, wie gesagt, mit Visual Studio.

Grüssli

Vielleicht versuchst Du es trotzdem mal damit. Im Zweifelsfall mit VirtualBox unter Windows.

Fellhuhn

Dann schließe ich daraus vollkommen logisch und niemand kann mir da aufgrund meiner perfekten Argumentation widersprechen: Visual Studio ist schuld. SCNR

Dravere

Tachyon schrieb:

Vielleicht versuchst Du es trotzdem mal damit. Im Zweifelsfall mit VirtualBox unter Windows.

Witzbold
Dir ist schon klar, dass ich dann eine Ausführbare Datei erstelle für Linux und nicht mehr für Windows? Da muss ich dann auch einen anderen Compiler verwenden. Kannst mir gleich vorschlagen, dass ich künftig auf Linux mit Code::Blocks entwickeln soll, kommt auf das gleiche raus

Fellhuhn schrieb:

Dann schließe ich daraus vollkommen logisch und niemand kann mir da aufgrund meiner perfekten Argumentation widersprechen: Visual Studio ist schuld. SCNR

Du meinst es nicht ernst, aber grundsätzlich hast du recht! Visual Studio ist halt eine IDE für "Profis", bzw. für Firmen. Deshalb sind auch alle Add-Ons und co entsprechend auf solche Kunden ausgerichtet. Was dazu führt, dass die Dinger was kosten, so dass sich eine Firma sowas leisten kann, ein Hobbyprogrammierer aber Mühe hat.

Ich könnte natürlich auf Code::Blocks mit dem g++ entwickeln. Dann könnte ich gprof nehmen, welcher in Code::Blocks sogar ein Interface hat. Nur mir persönlich gefällt Code::Blocks nicht so richtig. Vor allem VAX würde ich auf Code::Blocks extrem vermissen ...

Grüssli

Tachyon

Dann hast Du doch einen guten Anreiz dafür, dass der Code sowohl unter Linux als auch Windows compiliert.

Verschiedene Aufrufe -&gt; Unerklärlicher Mehraufwand

Verschiedene Aufrufe -> Unerklärlicher Mehraufwand