Unterschied zwischen Rdtscp, Rdtsc: Speicher und CPU/Rdtsc?

Question

Angenommen, wir versuchen, den TSC zur Leistungsüberwachung zu verwenden, und wir wollen verhindern, dass Befehle neu angeordnet werden.

Dies sind unsere Optionen:

1:rdtscp ist eine Serialisierung Anruf. Es verhindert eine Neuanordnung des Aufrufs von rdtscp.

__asm__ __volatile__("rdtscp; "   // serializing read of tsc 
        "shl $32,%%rdx; " // shift higher 32 bits stored in rdx up 
        "or %%rdx,%%rax" // and or onto rax 
        : "=a"(tsc)  // output to tsc variable 
        : 
        : "%rcx", "%rdx"); // rcx and rdx are clobbered 

ist jedoch rdtscp nur auf neueren CPUs zur Verfügung. In diesem Fall müssen wir rdtsc verwenden. Aber rdtsc ist nicht serialisierend, so dass es die CPU nicht daran hindert, sie neu zu ordnen.

So können wir eine dieser beiden Optionen verwenden, um Neuanordnung zu verhindern:

2: Dies ist ein Aufruf an cpuid und dann rdtsc. cpuid ist ein Serialisierungsaufruf.

volatile int dont_remove __attribute__((unused)); // volatile to stop optimizing 
unsigned tmp; 
__cpuid(0, tmp, tmp, tmp, tmp);     // cpuid is a serialising call 
dont_remove = tmp;        // prevent optimizing out cpuid 

__asm__ __volatile__("rdtsc; "   // read of tsc 
        "shl $32,%%rdx; " // shift higher 32 bits stored in rdx up 
        "or %%rdx,%%rax" // and or onto rax 
        : "=a"(tsc)  // output to tsc 
        : 
        : "%rcx", "%rdx"); // rcx and rdx are clobbered 

3: Dies ist ein Aufruf an rdtsc mit memory in der clobber Liste, die

Neuordnungs verhindert

__asm__ __volatile__("rdtsc; "   // read of tsc 
        "shl $32,%%rdx; " // shift higher 32 bits stored in rdx up 
        "or %%rdx,%%rax" // and or onto rax 
        : "=a"(tsc)  // output to tsc 
        : 
        : "%rcx", "%rdx", "memory"); // rcx and rdx are clobbered 
                // memory to prevent reordering 

Mein Verständnis für die dritte Option ist wie folgt:

die Herstellung Der Aufruf __volatile__ verhindert, dass der Optimierer die ASM entfernt oder sie über irgendwelche Anweisungen bewegt, die die Ergebnisse (oder die Eingaben) der ASM benötigen könnten. Es könnte jedoch immer noch in Bezug auf nicht verwandte Operationen verschoben werden. Also __volatile__ ist nicht genug.

Sagen Sie dem Compilerspeicher wird geplätschert: : "memory"). Der "memory" Clobber bedeutet, dass GCC keine Annahmen über Speicherinhalte treffen kann, die über die asm gleich bleiben und daher nicht um sie herum neu angeordnet werden.

So sind meine Fragen:

• 1: Ist mein Verständnis von __volatile__ und "memory" richtig?
• 2: Machen die zweiten beiden Anrufe dasselbe?
• 3: Die Verwendung von "memory" sieht viel einfacher aus als die Verwendung einer anderen Serialisierungsanweisung. Warum sollte jemand die dritte Option über die zweite Option verwenden?

Answer 1

Wie in einem Kommentar erwähnt, gibt es einen Unterschied zwischen einer Compiler Barriere und einer Prozessor Barriere. volatile und memory in der asm-Anweisung fungieren als eine Compiler-Barriere, aber der Prozessor ist immer noch frei, Anweisungen neu zu ordnen.

Prozessorbarriere sind spezielle Anweisungen, die explizit angegeben werden müssen, z. rdtscp, cpuid, Speicherzaun Anweisungen (mfence, lfence, ...) usw.

Als Nebenwirkung bei der Verwendung von cpuid als Barriere vor rdtsc üblich ist, kann es auch aus Sicht der Leistung sehr schlecht, da virtueller Maschine Plattformen oft Trap und emulieren die cpuid Anweisung, um einen gemeinsamen Satz von CPU zu verhängen Features auf mehreren Computern in einem Cluster (um sicherzustellen, dass Live-Migration funktioniert). Daher ist es besser, eine der Speicherzaun-Anweisungen zu verwenden.

Der Linux-Kernel verwendet mfence;rdtsc auf AMD-Plattformen und lfence;rdtsc auf Intel. Wenn Sie sich nicht damit auseinandersetzen wollen, funktioniert mfence;rdtsc auf beiden, obwohl es etwas langsamer ist, da mfence eine stärkere Barriere als lfence ist.

Answer 2

Sie können es unten verwenden wie:

asm volatile (
"CPUID\n\t"/*serialize*/ 
"RDTSC\n\t"/*read the clock*/ 
"mov %%edx, %0\n\t" 
"mov %%eax, %1\n\t": "=r" (cycles_high), "=r" 
(cycles_low):: "%rax", "%rbx", "%rcx", "%rdx"); 
/* 
Call the function to benchmark 
*/ 
asm volatile (
"RDTSCP\n\t"/*read the clock*/ 
"mov %%edx, %0\n\t" 
"mov %%eax, %1\n\t" 
"CPUID\n\t": "=r" (cycles_high1), "=r" 
(cycles_low1):: "%rax", "%rbx", "%rcx", "%rdx"); 

In dem obigen Code implementiert der erste CPUID Aufruf eine Barriere out-of-order oberhalb und unterhalb der RDTSC Anweisung der Ausführung der Befehle zu vermeiden. Mit dieser Methode vermeiden wir den Aufruf eines CPUID-Befehls zwischen den Lesevorgängen der Echtzeitregister.

Das erste RDTSC liest dann das Zeitstempelregister und der Wert wird im Speicher gespeichert. Dann wird der Code, den wir messen wollen, ausgeführt. Der RDTSCP-Befehl liest das Zeitstempelregister zum zweiten Mal und garantiert, dass die Ausführung des gesamten Codes, den wir messen wollten, abgeschlossen ist. Die zwei "mov" -Anweisungen, die danach kommen, speichern die edx- und eax-Registerwerte im Speicher. Schließlich garantiert ein CPUID-Aufruf, dass eine Barriere erneut implementiert wird, so dass es unmöglich ist, dass ein später kommender Befehl vor der CPUID selbst ausgeführt wird.