Differenza tra rdtscp, rdtsc: memoria e cpuid/rdtsc?

Question

Supponiamo di provare a utilizzare il tsc per il monitoraggio delle prestazioni e vogliamo evitare il riordino delle istruzioni.

Queste sono le nostre opzioni:

1:rdtscp è una chiamata serializzazione. Impedisce il riordino della chiamata a 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 

Tuttavia, rdtscp è disponibile solo su CPU più recenti. Quindi in questo caso dobbiamo usare rdtsc. Ma rdtsc non è serializzato, quindi usarlo da solo non impedirà alla CPU di riordinarlo.

modo che possiamo utilizzare una di queste due opzioni per evitare riordino:

2: Questa è una chiamata alla cpuid e poi rdtsc. cpuid è una chiamata di serializzazione.

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: Questa è una chiamata a rdtsc con memory nella lista clobber, che impedisce riordino

__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 

mia comprensione per il 3 ° opzione è la seguente:

Rendere il chiamare __volatile__ impedisce all'ottimizzatore di rimuovere asm o spostarlo attraverso qualsiasi istruzione che potrebbe richiedere i risultati (o modificare gli input) di asm. Tuttavia potrebbe ancora spostarlo rispetto alle operazioni non correlate. Quindi __volatile__ non è sufficiente.

Comunica che la memoria del compilatore è stata danneggiata: : "memory"). Il clobber "memory" significa che GCC non può fare supposizioni sul fatto che il contenuto della memoria rimanga lo stesso su ASM, e quindi non lo riordina attorno ad esso.

Quindi le mie domande sono:

• 1: E 'la mia comprensione della __volatile__ e "memory" corretta?
• 2: le seconde due chiamate fanno la stessa cosa?
• 3: L'utilizzo di "memory" sembra molto più semplice dell'utilizzo di un'altra istruzione di serializzazione. Perché qualcuno dovrebbe usare la terza opzione sulla seconda opzione?

Answer 1

Come menzionato in un commento, c'è una differenza tra una barriera compilatore ed una barriera processore . volatile e memory nella dichiarazione ASM fungono da barriera del compilatore, ma il processore è ancora libero di riordinare le istruzioni.

La barriera del processore è istruzioni speciali che devono essere espressamente fornite, ad es. rdtscp, cpuid, istruzioni della barriera di memoria (mfence, lfence, ...) ecc.

Per inciso, mentre usando cpuid come barriera prima rdtsc è comune, può anche essere molto male dal punto di vista delle prestazioni, in quanto piattaforme di macchine virtuali spesso trappola e emulare l'istruzione cpuid per imporre un insieme comune di CPU funzionalità su più macchine in un cluster (per garantire che la migrazione live funzioni). Quindi è meglio usare una delle istruzioni della recinzione di memoria.

Il kernel Linux utilizza mfence;rdtsc su piattaforme AMD e su Intel. Se non vuoi preoccuparti di distinguere tra questi, mfence;rdtsc funziona su entrambi, anche se è leggermente più lento come mfence è una barriera più forte di lfence.

Answer 2

è possibile utilizzarlo come indicato qui sotto:

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"); 

Nel codice di cui sopra, la prima chiamata CPUID implementa una barriera per evitare l'esecuzione out-of-order delle istruzioni sopra e sotto le istruzioni RDTSC. Con questo metodo evitiamo di chiamare un'istruzione CPUID tra le letture dei registri in tempo reale

Il primo RDTSC legge quindi il registro timestamp e il valore è memorizzato nella memoria . Quindi viene eseguito il codice che vogliamo misurare. L'istruzione RDTSCP legge il registro timestamp per la seconda volta e garantisce che l'esecuzione di tutto il codice che volevamo misurare sia completata. Le due istruzioni "mov" in seguito memorizzano i valori dei registri edx e eax in memoria. Infine, una chiamata CPUID garantisce che una barriera venga implementata di nuovo in modo tale che sia impossibile che qualsiasi istruzione venga successivamente eseguita prima di CPUID stessa.