Il loop sta srotolando uno degli esempi di compilazione "mirata" e un set di istruzioni più veloce?

4

Sto seguendo il corso di Computer Architecture nel mio studio universitario.

Vedo che durante lo srotolamento del ciclo, uno dei vincoli è il numero di registri disponibili.

Poiché il numero di registri dipende dall'architettura, è un binario precompilato generico destinato al caso peggiore (numero minimo di registri disponibili)?

So che un software compilato dalla fonte è più veloce del download di un binario precompilato, e la ragione viene spesso spiegata come l'assembly generato più "mirato". Il ciclo srotola uno degli esempi di questa compilation "mirata"? Come in, un software compilato per un processore con più registri rispetto al caso generico utilizzerà TUTTI quei registri per i suoi loop?

    
posta U. Muneeb 06.10.2016 - 08:25
fonte

3 risposte

3

Since the number of registers depends on the architecture, is a generic pre-compiled binary targeted for the worst case (least number of available registers)?

Non esiste davvero un binario precompilato generico. I binari compilati sono necessariamente destinati a una specifica Architettura dell'insieme di istruzioni e a uno specifico Interfaccia binaria di applicazione . Lo stesso binario non verrà eseguito su un ISA diverso o su un ABI diverso, dovrà essere ricompilato per questo.

È l'ISA che definisce il set di registri hardware disponibile; l'ABI definisce come il software può utilizzare i registri, specialmente quando si tratta di chiamate di funzione.

Durante la compilazione, l'ISA e l'ABI vengono selezionati scegliendo il compilatore appropriato o, a volte, le opzioni del compilatore.

Ad esempio, x86 è un'Intel Set Architecture a 32 bit intel che specifica ~ 8 registri a 32 bit (senza contare alcun registro in virgola mobile o xmm).

x64, dall'altra ha avuto ~ 16 registri a 64 bit. E ci sono anche altri processori.

Un binario compilato per x86 di solito esegue in modalità di compatibilità a 32 bit come una caratteristica di un processore x64 , tuttavia, un x64 compilato-binario non verrà eseguito su un x86. (Quando un processore x64 esegue un binario x86 che binario viene eseguito con le risorse dell'architettura dell'insieme di istruzioni a 32 bit, vale a dire che è limitato ai registri ~ 8 a 32 bit e ha anche un limite di spazio di indirizzi di 4 GB; non ha accesso ai 16 registri a 64 bit o agli indirizzi più grandi.)

Inoltre, un file binario compilato per Windows non verrà eseguito su Linux e viceversa a causa delle differenze ABI, anche per lo stesso ISA.

Is the loop unrolling one of the examples of this “targeted” compilation?

Tutta la compilation "pre" è mirata a una coppia ISA e ABI esatta.

As in, a software compiled for a processor with more registers than the generic case will utilize ALL those registers for its loops?

Sì, fino a un certo punto. Ma direi che non esiste un caso generico, ci sono casi specifici.

C'è un'area di compilazione che è più dinamica, e questa è Just in Time Compiling o JITing in breve. Sia Java che C # utilizzano entrambi un modulo binario intermedio chiamato codice byte (diverso per ciascuno, ovviamente), quindi eseguono la compilazione finale sul computer di destinazione in fase di runtime. Poiché il runtime conosce meglio l'attuale processore su cui è in esecuzione, può fare un lavoro migliore di gestione della compilazione non solo per ISA e ABI specifici, ma anche per il processore specifico. Questo include i registri e influisce sull'uso di funzioni opzionali del processore, come i registri XMM. Ad esempio, in C # è possibile scrivere codice che utilizza le estensioni del processore SIMD e, se tale hardware è presente (cioè è attualmente in esecuzione su un processore più costoso o più moderno), il JIT genererà il codice per utilizzarli e se l'hardware non è presente, non lo farà.

In un ambiente "pre" compilato, dovresti creare due binari precompilati separati per questo.

    
risposta data 06.10.2016 - 17:07
fonte
2

Considerando lo svolgimento del ciclo da solo, è proprio questo: salva il codice di iterazione, quindi non lo considererei "mirato".

Tuttavia, abilita tutti i tipi di altre ottimizzazioni, che potrebbero utilizzare l'architettura data. Riorganizzando le operazioni e / o eseguendole in parallelo / vettoriale, alcuni di questi potrebbero beneficiare di più registri, altri no. Alcuni che sicuramente rientrano nella categoria "mirata".

Considera un ciclo stretto che richiama solo una funzione pesante rispetto a una che fa una moltiplicazione vettoriale. Dipende

    
risposta data 06.10.2016 - 09:21
fonte
2

Lo srotolamento del loop potrebbe aumentare (o diminuire) l'utilizzo del registro, che dipende dal codice all'interno del ciclo e dal compilatore. L'argomento è discusso controverso in questa pagina "Dubbia" di Wikipedia sullo srotolamento del ciclo. Quindi lo srotolamento del loop può portare a un codice in cui il guadagno di ottimizzazione funziona meglio su una macchina, e peggio su un'altra, ma dipende strongmente dal singolo caso.

    
risposta data 06.10.2016 - 08:58
fonte

Leggi altre domande sui tag