Trasferimento di memoria in alto da e verso un microfono Intel

Question

Sto osservando uno strano comportamento e vorrei sapere se è Intel Xeon PHI correlato o no.

Ho un piccolo codice di esempio, fondamentalmente la moltiplicazione della matrice che tutti sanno (tre nidificati per i loop). Scaricalo il calcolo in un microfono Intel con OpenMP 4.0 target Pragma e mappare le tre matrici con map(to:A,B) map(tofrom:C).

Ora, quello che sto osservando è che per le matrici piccole e.g. 1024x1024 Il trasferimento della memoria ha preso estremamente a lungo. Rispetto alla versione nativa (lo stesso codice, la stessa strategia di parallelizzazione, solo nessun scarico) La versione di scarica consente di consumare circa 320 ms più tempo. Ho fatto una corsa di riscaldamento del codice per rimuovere il sovraccarico di inizializzazione.

Rispetto a una Nvidia Tesla K20 dove viene copiata la stessa quantità di memoria senza notare che questo 320ms è pessimo.

Ci sono alcune impostazioni dell'ambiente che possono migliorare la velocità di trasferimento della memoria?

Una domanda aggiuntiva: Ho permesso di scaricare il reporting di offload tramite la variabile di ambiente Offload_report. Quali sono le differenze tra i due risultati temporali visualizzati nel rapporto:

[Offload] [HOST]  [Tag 5] [CPU Time]        26.995279(seconds)
[Offload] [MIC 0] [Tag 5] [CPU->MIC Data]   3221225480 (bytes)
[Offload] [MIC 0] [Tag 5] [MIC Time]        16.859548(seconds)
[Offload] [MIC 0] [Tag 5] [MIC->CPU Data]   1073741824 (bytes)

.

Quali sono i 10 secondi mancanti a Mic Time (Memory Transfer?)

bene una terza domanda. È possibile utilizzare la memoria appuntata con Intel MICS? Se sì, come?

Answer 1

È probabile che l'allocazione della memoria su MIC che sta prendendo tempo.Prova a separare le tre fonti del sovraccarico per capire meglio dove va il tempo:

// Device initialization
#pragma offload_transfer target(mic)
...
// Memory allocation and first data transfer
// This is expected to have overhead proportional to the amount of memory allocated
// Doing at least one transfer will speed up subsequent transfers
#pragma offload_transfer target(mic) in(p[0:SIZE] : alloc_if(1) free_if(0))

...
// This transfer should be faster
// For large sizes, approaching 6 GiB/s
#pragma offload_transfer target(mic) in(p[0:SIZE] : alloc_if(0) free_if(0))

.

Answer 2

Dato che hai detto "Ho fatto una corsa di riscaldamento del codice per rimuovere il sovraccarico di inizializzazione", presumo che tu abbia avviato il runtime di scarico scaricando una sezione fittizia. Ricordo che c'è un aggiustamento per avviarlo "on_offload" (predefinito) o al tempo di inizializzazione del programma (offload_init= on_start). In ogni caso, c'è anche un sentiero veloce nel motore DMA. Il percorso veloce viene preso quando i buffer (da trasferire) sono allineati alla dimensione della pagina. Per un'applicazione di scarica, è possibile impostare semplicemente una variabile di ambiente insieme a una soglia integerb | k | m | g | t dove m è megabyte (ad esempio, mic_use_2mb_buffers= 2m). Questa soglia definisce la dimensione del buffer che è necessario prima che vengano utilizzate le pagine enormi. Quindi ottieni due cose: pagine enormi e trasferimenti più veloci! Questa funzione è ancora significativa anche con pagine trasparenti enormi (THP) introdotte sul coprocessore.

Dopo aver semplicemente provato offload_init= on_start e mic_use_2mb_buffer= 0, è possibile allineare i buffer sul lato host di conseguenza (massimo. Ricorda, senza ulteriori clausole di scarica (Leo; ma non sono sicuro di OpenMP 4.0) L'allineamento del buffer host è semplicemente ereditato da una sezione di scarica. Allineamento a 2 MB dovrebbe coprire tutto (ma è possibile rendere la tua allocazione molto più intelligente per evitare di sprecare risorse per piccoli buffer). Con ciò dovresti avere abbastanza parole chiave per trovare più sfondo se hai bisogno.