Perché l'introduzione di inutili istruzioni MOV accelererebbe un ciclo stretto nell'assemblaggio x86_64?

Sfondo:

Durante l'ottimizzazione del codice Pascal con linguaggio assembly incorporato, ho notato un'istruzione non necessaria MOVe l'ho rimosso.

Con mia sorpresa, la rimozione delle istruzioni non necessarie ha fatto rallentare il mio programma .

Ho scoperto che l' aggiunta di MOVistruzioni arbitrarie e inutili ha aumentato ulteriormente le prestazioni .

L'effetto è irregolare e cambia in base all'ordine di esecuzione: le stesse istruzioni spazzatura trasposte su o giù da una singola riga producono un rallentamento .

Capisco che la CPU fa tutti i tipi di ottimizzazioni e ottimizzazione, ma sembra più una magia nera.

I dati:

Una versione del mio codice compila in modo condizionale tre operazioni spazzatura nel mezzo di un ciclo che esegue i 2**20==1048576tempi. (Il programma circostante calcola solo gli hash SHA-256 ).

I risultati sulla mia macchina piuttosto vecchia (Intel (R) Core (TM) 2 CPU 6400 a 2,13 GHz):

avg time (ms) with -dJUNKOPS: 1822.84 ms
avg time (ms) without:        1836.44 ms

I programmi sono stati eseguiti 25 volte in un ciclo, con l'ordine di esecuzione che cambia ogni volta in modo casuale.

Estratto:

{$asmmode intel}
procedure example_junkop_in_sha256;
  var s1, t2 : uint32;
  begin
    // Here are parts of the SHA-256 algorithm, in Pascal:
    // s0 {r10d} := ror(a, 2) xor ror(a, 13) xor ror(a, 22)
    // s1 {r11d} := ror(e, 6) xor ror(e, 11) xor ror(e, 25)
    // Here is how I translated them (side by side to show symmetry):
  asm
    MOV r8d, a                 ; MOV r9d, e
    ROR r8d, 2                 ; ROR r9d, 6
    MOV r10d, r8d              ; MOV r11d, r9d
    ROR r8d, 11    {13 total}  ; ROR r9d, 5     {11 total}
    XOR r10d, r8d              ; XOR r11d, r9d
    ROR r8d, 9     {22 total}  ; ROR r9d, 14    {25 total}
    XOR r10d, r8d              ; XOR r11d, r9d

    // Here is the extraneous operation that I removed, causing a speedup
    // s1 is the uint32 variable declared at the start of the Pascal code.
    //
    // I had cleaned up the code, so I no longer needed this variable, and 
    // could just leave the value sitting in the r11d register until I needed
    // it again later.
    //
    // Since copying to RAM seemed like a waste, I removed the instruction, 
    // only to discover that the code ran slower without it.
    {$IFDEF JUNKOPS}
    MOV s1,  r11d
    {$ENDIF}

    // The next part of the code just moves on to another part of SHA-256,
    // maj { r12d } := (a and b) xor (a and c) xor (b and c)
    mov r8d,  a
    mov r9d,  b
    mov r13d, r9d // Set aside a copy of b
    and r9d,  r8d

    mov r12d, c
    and r8d, r12d  { a and c }
    xor r9d, r8d

    and r12d, r13d { c and b }
    xor r12d, r9d

    // Copying the calculated value to the same s1 variable is another speedup.
    // As far as I can tell, it doesn't actually matter what register is copied,
    // but moving this line up or down makes a huge difference.
    {$IFDEF JUNKOPS}
    MOV s1,  r9d // after mov r12d, c
    {$ENDIF}

    // And here is where the two calculated values above are actually used:
    // T2 {r12d} := S0 {r10d} + Maj {r12d};
    ADD r12d, r10d
    MOV T2, r12d

  end
end;

Provate voi stessi:

Il codice è online su GitHub se vuoi provarlo tu stesso.

Le mie domande:

• Perché copiare inutilmente i contenuti di un registro nella RAM aumenterebbe mai le prestazioni?
• Perché la stessa inutile istruzione fornirebbe un aumento di velocità su alcune linee e un rallentamento su altre?
• Questo comportamento è qualcosa che potrebbe essere sfruttato in modo prevedibile da un compilatore?

La causa più probabile del miglioramento della velocità è che:

• l'inserimento di un MOV sposta le istruzioni successive su diversi indirizzi di memoria
• una di quelle istruzioni spostate era un ramo condizionale importante
• quel ramo era stato erroneamente previsto a causa dell'aliasing nella tabella di previsione del ramo
• lo spostamento del ramo ha eliminato l'alias e ha consentito di prevedere correttamente il ramo

Il tuo Core2 non tiene un registro storico separato per ogni salto condizionale. Invece mantiene una cronologia condivisa di tutti i salti condizionati. Uno svantaggio della previsione del ramo globale è che la storia è diluita da informazioni irrilevanti se i diversi salti condizionali non sono correlati.

Questo piccolo tutorial di previsione dei rami mostra come funzionano i buffer di previsione dei rami. Il buffer della cache è indicizzato dalla parte inferiore dell'indirizzo dell'istruzione di diramazione. Funziona bene a meno che due importanti rami non correlati condividano gli stessi bit inferiori. In tal caso, si finisce con l'aliasing che causa molti rami non previsti (che blocca la pipeline di istruzioni e rallenta il programma).

Se vuoi capire come le cattive previsioni del ramo influenzano le prestazioni, dai un'occhiata a questa eccellente risposta: https://stackoverflow.com/a/11227902/1001643

I compilatori in genere non dispongono di informazioni sufficienti per sapere quali rami saranno alias e se tali alias saranno significativi. Tuttavia, tali informazioni possono essere determinate in fase di esecuzione con strumenti come Cachegrind e VTune .

Potresti voler leggere http://research.google.com/pubs/pub37077.html

TL; DR: l'inserimento casuale delle istruzioni nop nei programmi può facilmente aumentare le prestazioni del 5% o più, e no, i compilatori non possono sfruttarlo facilmente. Di solito è una combinazione di predittore di diramazione e comportamento della cache, ma può anche essere, ad esempio, uno stallo della stazione di prenotazione (anche nel caso in cui non vi siano catene di dipendenze rotte o evidenti sovra-abbonamenti di sorta).

Credo nelle CPU moderne le istruzioni di assemblaggio, pur essendo l'ultimo strato visibile a un programmatore per fornire istruzioni di esecuzione a una CPU, in realtà sono diversi livelli dall'esecuzione effettiva da parte della CPU.

Le moderne CPU sono ibridi RISC / CISC che traducono le istruzioni CISC x86 in istruzioni interne che presentano un comportamento più RISC. Inoltre ci sono analizzatori di esecuzione fuori servizio, predittori di diramazioni, "micro-ops fusion" di Intel che cercano di raggruppare le istruzioni in grandi lotti di lavoro simultaneo (un po 'come il titanio VLIW / Itanium ). Esistono persino limiti della cache che potrebbero rendere il codice più veloce per god-know-why se è più grande (forse il controller della cache lo inserisce in modo più intelligente o lo mantiene più a lungo).

Il CISC ha sempre avuto un livello di traduzione da assembly a microcodice, ma il punto è che con le CPU moderne le cose sono molto più complicate. Con tutte le proprietà extra di transistor nei moderni impianti di fabbricazione di semiconduttori, le CPU possono probabilmente applicare diversi approcci di ottimizzazione in parallelo e quindi selezionare quello alla fine che fornisce la migliore velocità. Le istruzioni aggiuntive potrebbero influenzare la CPU a utilizzare un percorso di ottimizzazione migliore di altri.

L'effetto delle istruzioni aggiuntive dipende probabilmente dal modello / generazione / produttore della CPU e non è probabile che sia prevedibile. L'ottimizzazione del linguaggio assembly in questo modo richiederebbe l'esecuzione contro molte generazioni di architetture di CPU, magari utilizzando percorsi di esecuzione specifici della CPU, e sarebbe auspicabile solo per sezioni di codice veramente importanti, anche se probabilmente si sta già eseguendo un assembly.

Preparare la cache

Le operazioni di spostamento in memoria possono preparare la cache e rendere più veloci le successive operazioni di spostamento. Una CPU di solito ha due unità di carico e una unità di memoria. Un'unità di carico può leggere dalla memoria in un registro (una lettura per ciclo), un'unità di memoria memorizza dal registro alla memoria. Esistono anche altre unità che eseguono operazioni tra i registri. Tutte le unità lavorano in parallelo. Pertanto, su ogni ciclo, possiamo eseguire più operazioni contemporaneamente, ma non più di due carichi, un magazzino e diverse operazioni di registro. Di solito sono fino a 4 semplici operazioni con registri semplici, fino a 3 semplici operazioni con registri XMM / YMM e 1-2 operazioni complesse con qualsiasi tipo di registri. Il tuo codice ha molte operazioni con i registri, quindi un'operazione di memorizzazione di memoria fittizia è gratuita (poiché ci sono comunque più di 4 operazioni di registro), ma prepara la cache di memoria per l'operazione di archiviazione successiva. Per scoprire come funzionano gli archivi di memoria, fare riferimento aManuale di riferimento per l'ottimizzazione delle architetture Intel 64 e IA-32 .

Rompere le false dipendenze

Anche se questo non si riferisce esattamente al tuo caso, ma a volte usando operazioni di movimentazione a 32 bit sotto il processore a 64 bit (come nel tuo caso) vengono utilizzati per cancellare i bit più alti (32-63) e interrompere le catene di dipendenza.

È noto che in x86-64, l'utilizzo di operandi a 32 bit cancella i bit più alti del registro a 64 bit. Si prega di leggere la sezione pertinente - 3.4.1.1 - del Manuale per gli sviluppatori del software per le architetture Intel® 64 e IA-32 Volume 1 :

Gli operandi a 32 bit generano un risultato a 32 bit, con estensione zero fino a un risultato a 64 bit nel registro di destinazione generale

Quindi, le istruzioni mov, che possono sembrare inutili a prima vista, cancellano i bit più alti dei registri appropriati. Cosa ci dà? Rompe le catene di dipendenze e consente l'esecuzione delle istruzioni in parallelo, in ordine casuale, dall'algoritmo Out-of-Order implementato internamente dalle CPU dal Pentium Pro nel 1995.

Un preventivo dal Manuale di riferimento per l'ottimizzazione delle architetture Intel® 64 e IA-32 , Sezione 3.5.1.8:

Le sequenze di codici che modificano il registro parziale possono subire alcuni ritardi nella sua catena di dipendenze, ma possono essere evitate usando i modi di dire di rottura delle dipendenze. Nei processori basati sulla microarchitettura Intel Core, una serie di istruzioni può aiutare a cancellare la dipendenza dall'esecuzione quando il software utilizza queste istruzioni per azzerare il contenuto del registro. Rompere le dipendenze da porzioni di registri tra le istruzioni operando su registri a 32 bit anziché su registri parziali. Per le mosse, ciò può essere realizzato con mosse a 32 bit o utilizzando MOVZX.

Regola di codifica assembly / compilatore 37. (Impatto M, generalità MH) : Rompere le dipendenze su porzioni di registri tra le istruzioni operando su registri a 32 bit anziché su registri parziali. Per le mosse, ciò può essere realizzato con mosse a 32 bit o utilizzando MOVZX.

MOVZX e MOV con operandi a 32 bit per x64 sono equivalenti: interrompono tutti le catene di dipendenza.

Ecco perché il tuo codice viene eseguito più velocemente. Se non ci sono dipendenze, la CPU può rinominare internamente i registri, anche se a prima vista può sembrare che la seconda istruzione modifichi un registro usato dalla prima istruzione e che i due non possano essere eseguiti in parallelo. Ma a causa della ridenominazione del registro possono farlo.

La ridenominazione dei registri è una tecnica utilizzata internamente da una CPU che elimina le false dipendenze dei dati derivanti dal riutilizzo dei registri mediante istruzioni successive che non hanno alcuna reale dipendenza tra i dati.

Penso che ora vedi che è troppo ovvio.