Memcpia molto veloce per l'elaborazione delle immagini?

Question

Sto eseguendo l'elaborazione delle immagini in C che richiede di copiare grandi quantità di dati intorno alla memoria - la sorgente e la destinazione non si sovrappongono mai.

Qual è il modo più veloce per eseguire questa operazione sulla piattaforma x86 utilizzando GCC (dove sono disponibili SSE, SSE2 ma NON SSE3)?

Mi aspetto che la soluzione sia in assembly o utilizzando gli elementi intrinseci di GCC?

ho trovato il seguente link, ma non hanno alcuna idea se è il modo migliore per andare su di esso (l'autore dice anche che ha qualche bug): http://coding.derkeiler.com/Archive/Assembler/comp.lang.asm.x86/2006-02/msg00123.html

EDIT: si noti che una copia è necessario, non posso andare in giro dovendo copiare i dati (posso spiegare perché ma ti risparmierò la spiegazione :))

Answer 1

Per gentile concessione di William Chan e Google. 30-70% più veloce rispetto memcpy in Microsoft Visual Studio 2005.

void X_aligned_memcpy_sse2(void* dest, const void* src, const unsigned long size) 
{ 

    __asm 
    { 
    mov esi, src; //src pointer 
    mov edi, dest; //dest pointer 

    mov ebx, size; //ebx is our counter 
    shr ebx, 7;  //divide by 128 (8 * 128bit registers) 


    loop_copy: 
     prefetchnta 128[ESI]; //SSE2 prefetch 
     prefetchnta 160[ESI]; 
     prefetchnta 192[ESI]; 
     prefetchnta 224[ESI]; 

     movdqa xmm0, 0[ESI]; //move data from src to registers 
     movdqa xmm1, 16[ESI]; 
     movdqa xmm2, 32[ESI]; 
     movdqa xmm3, 48[ESI]; 
     movdqa xmm4, 64[ESI]; 
     movdqa xmm5, 80[ESI]; 
     movdqa xmm6, 96[ESI]; 
     movdqa xmm7, 112[ESI]; 

     movntdq 0[EDI], xmm0; //move data from registers to dest 
     movntdq 16[EDI], xmm1; 
     movntdq 32[EDI], xmm2; 
     movntdq 48[EDI], xmm3; 
     movntdq 64[EDI], xmm4; 
     movntdq 80[EDI], xmm5; 
     movntdq 96[EDI], xmm6; 
     movntdq 112[EDI], xmm7; 

     add esi, 128; 
     add edi, 128; 
     dec ebx; 

     jnz loop_copy; //loop please 
    loop_copy_end: 
    } 
} 

Si può essere in grado di ottimizzare ulteriormente a seconda della situazione esatta e qualsiasi ipotesi si è in grado di fare.

Si consiglia inoltre di controllare la fonte memcpy (memcpy.asm) e rimuovere la gestione caso speciale. Potrebbe essere possibile ottimizzare ulteriormente!

Answer 2

Se sei su Windows, usa le API DirectX, che ha specifiche routine GPU-ottimizzate per la gestione della grafica (quanto velocemente potrebbe essere? La tua CPU non è caricata. Fai qualcos'altro mentre la GPU la mastica).

Se si desidera essere indipendenti dal sistema operativo, provare OpenGL.

Non smettere di armeggiare con l'assemblatore, perché è troppo probabile che fallirai miseramente per superare gli ingegneri del software di 10 anni e più esperti nella creazione di librerie.

Answer 3

Se specifico per i processori Intel, è possibile trarre vantaggio da IPP. Se sai che verrà eseguito con una GPU Nvidia, potresti usare CUDA - in entrambi i casi potrebbe essere meglio sembrare più ampio dell'ottimizzazione di memcpy() - offrono opportunità per migliorare l'algoritmo a un livello più alto. Entrambi sono tuttavia dipendenti da hardware specifico.

Answer 4

A qualsiasi livello di ottimizzazione di -O1 o superiore, GCC utilizzerà le definizioni incorporati per funzioni come memcpy - con il parametro di -march destra (-march=pentium4 per l'insieme delle caratteristiche si parla) che dovrebbe generare codice inline specifico per la graziosa architettura ottimale.

Vorrei confrontarlo e vedere cosa viene fuori.

Answer 5

Il codice SSE pubblicato da hapalibashi è la strada da percorrere.

Se avete bisogno di prestazioni ancora maggiori e non evitate la lunga e tortuosa strada della scrittura di un dispositivo-driver: tutte le piattaforme importanti oggi hanno un controller DMA che è in grado di fare un lavoro di copia più veloce e in potrebbe fare il codice parallelo alla CPU.

Ciò significa scrivere un driver. Nessun sistema operativo grande di cui sono a conoscenza espone questa funzionalità al lato utente a causa dei rischi per la sicurezza.

Tuttavia, potrebbe valerne la pena (se è necessaria la prestazione) poiché nessun codice sulla terra potrebbe superare la prestazione di un componente hardware progettato per svolgere tale lavoro.

Answer 6

Questa domanda ha ora quattro anni e sono un po 'sorpresa che nessuno abbia menzionato la larghezza di banda della memoria. CPU-Z segnala che la mia macchina ha una RAM PC3-10700. Che la RAM abbia un'ampiezza di banda di picco (ovvero velocità di trasferimento, velocità effettiva, ecc.) Di 10700 MByte/sec. La CPU nella mia macchina è una CPU i5-2430M, con una frequenza di picco del turbo di 3 GHz.

In teoria, con una CPU veloce e infinitamente la mia RAM, memcpy potrebbe andare a 5300 MByte/sec, vale a dire la metà di 10700 perché memcpy deve leggere e poi scrivere alla RAM. (modifica: come ho sottolineato, questa è un'approssimazione semplicistica).

D'altra parte, immagina di avere una RAM infinitamente veloce e una CPU realistica, cosa potremmo ottenere? Usiamo la mia CPU 3 GHz come esempio. Se potesse eseguire una lettura a 32 bit e una scrittura a 32 bit per ogni ciclo, potrebbe trasferire 3e9 * 4 = 12000 MByte/sec. Questo sembra facilmente alla portata di una CPU moderna. Già, possiamo vedere che il codice in esecuzione sulla CPU non è proprio il collo di bottiglia. Questo è uno dei motivi per cui le macchine moderne hanno cache di dati.

Siamo in grado di misurare ciò che la CPU può realmente fare eseguendo il benchmarking di memcpy quando sappiamo che i dati sono memorizzati nella cache. Fare questo con precisione è poco pratico. Ho creato una semplice app che ha scritto numeri casuali in un array, li abbiamo memcpy in un altro array, quindi ha eseguito il checksum dei dati copiati. Ho fatto un passo attraverso il codice nel debugger per assicurarmi che il compilatore intelligente non avesse rimosso la copia. La modifica della dimensione dell'array altera le prestazioni della cache: piccoli array si adattano alla cache, quelli grandi meno. Ho i seguenti risultati:

• 40 KByte array: 16000 MB/s
• 400 KByte array: 11000 MB/s
• 4000 matrici KByte: 3100 MByte/sec

Ovviamente, la mia CPU può leggere e scrivere più di 32 bit per ciclo, dal momento che 16000 è più del 12000 che ho calcolato teoricamente sopra. Ciò significa che la CPU è ancora meno un collo di bottiglia di quanto pensassi. Ho usato Visual Studio 2005 e, passando all'applicazione standard di memcpy, vedo che usa le istruzioni movqda sulla mia macchina. Immagino che questo possa leggere e scrivere 64 bit per ciclo.

Il bel codice pubblicato hamagibashi raggiunge 4200 MByte/sec sulla mia macchina, circa il 40% più veloce rispetto all'implementazione VS 2005. Immagino sia più veloce perché usa l'istruzione prefetch per migliorare le prestazioni della cache.

In sintesi, il codice in esecuzione sulla CPU non è il collo di bottiglia e l'ottimizzazione del codice comporterà solo piccoli miglioramenti.