2016-04-14 17 views
0

Ich möchte Zeit (oder Vorkommen) sehr spezifischer Teile in einem C-Code messen (sie können in einigen Funktionen auf einige Anweisungen beschränkt sein). Ein Zweck ist es, lokale Leistungsverbesserungen oder Regressionen über mehrere Code-Revisionen nachzuverfolgen.Instrument C-Code mit Anmerkungen (Pragmas) für die Leistungsverfolgung

Ich weiß, dass ich Makros für diesen Zweck definieren kann. Aber gibt es irgendein Werkzeug, das das schon in einem weniger aufdringlichen Weg tut? Verwendung von Annotationen (#pragma) wäre perfekt:

void func_to_profile() 
{ 
    /* Some instructions */ 
    ... 


#pragma profile foo start 
    /* A part of the code to track */ 
    ... 
#pragma profile foo stop 


    /* More instructions */ 
    ... 


#pragma profile bar start 
    /* Another part to measure */ 
    ... 
#pragma profile bar stop 
} 

Idealerweise am Ende des Laufes würde das Werkzeug die verstrichene kumulierte mal pro Unterabschnitte anzuzeigen. Zum Beispiel:

-- [foo] cumulated time: 42s 
-- [bar] cumulated time: 7s 

Gibt es ein vorhandenes Werkzeug, das bereits tut, oder habe ich keine andere Wahl, als meine eigenen GCC-Plugin entwickeln?

+0

Was ist der Unterschied zwischen dem Schreiben von '# Pragma' und dem Verwenden eines Makros? Anders als das Pragma hat keine Chance, tragbar zu sein, während Makros sein können? – Art

+1

Es gibt keine direkte Zuordnung zwischen den Zeilen von C und der optimierten asm-Ausgabe. Wenn der Compiler gezwungen wird, einen bestimmten Teil der Arbeit zwischen zwei Barrieren zu erledigen, könnte dies zu erheblich schlechterem Code führen. Am besten wägen Sie CPU-Leistungsindikatoren (z. B. linux 'perf') ab, um Ausführungs-Hotspots zu finden. Auf x86 ist sogar die leichteste Timing-Instrumentierung (CPUID) ~ 20 Zyklen Overhead, also ist es viel zu schwer, um nur ein paar Befehle zu messen. Verwenden Sie es, um alle Wiederholungen einer Schleife zusammen zu messen, nicht jede einzeln. –

+0

Wenn Sie dies tun, um Beschleunigungen zu finden, müssen Sie ein wenig anders darüber nachdenken. Sie haben sicherlich mehrere Möglichkeiten der Beschleunigung im Code, so dass nur eine von ihnen nicht gut genug ist. Die Chance, dass sie alle Hotspots sind, ist ziemlich klein. Probieren Sie eine [* -Methode aus, vor der sich Beschleuniger nicht verstecken können *] (http://Stackoverflow.com/a/25870103/23771). –

Antwort

0

perf record für ein Ereignis wie Kern-Taktzyklen werden Ereignisse zu Anweisungen akkumulieren. Es ist jedoch nicht präzise: Die Anweisungen, die die Ereigniszählungen erhalten, sind nicht immer diejenigen, die selbst langsam sind, nur in der Nähe und z.B. festgeklemmt darauf warten, dass die langsame Sache passiert. Aber nahe genug, um potenziell nützlich zu sein.

Es scheint, als ob Sie nur die Zählungen pro insn oder pro Zeile von C (Mapping via Debug-Info) sehen und sehen müssen, wenn sich die relative Anzahl ändert.

Das sollte funktionieren, um zu identifizieren, wenn eine Änderung einen bestimmten Teil der ASM langsamer laufen lässt: Der relative Anteil der Zählungen von Perf-Ereignissen ist höher für Insns, die dieser Quelllinie zugeordnet sind. (+/- viel von Hand winken, weil Zeilen C nicht immer direkt an asm Anweisungen Karte, insb. Wenn Optimierung restrukturiert eine Verzweigungslogik, Auto-vektorisiert usw.)


Es könnte sein, möglich, ein automatisiertes Testverfahren zu kochen, das Ihren Code unter ausführt, dann massiert die perf report Daten in eine Art Format, das verglichen werden kann, wenn Quellenversionen verglichen werden.