Newsgroup: it.comp.programmare
Titolo: MEMCPY o altri metodi per copiare buffer

che voi sapete utilizzano il DMA?
oppure i dati quando sono copiati da una locazione di memoria ad
un'altra utilizzano il processore?
(parlo di come vengono implementate in assembler)
grazie 

nonSonomaEsisto ha scritto:

Dipende dal processore, dal compilatore e dall'architettura del sistema.

 (parlo di come vengono implementate in assembler)
Di solito memcpy (e molte altre funzioni), se si compila con le
ottimizzazioni giuste attivate, non viene chiamata ma ci pensa il
compilatore ad inserire al suo posto il codice piu' performante per
l'architettura selezionata. Dipende dall'implementazione, ma sugli x86
e amd64, si usano generalmente i registri SSE2 se disponibili,
altrimenti si usano i registri MMX. Per processori che non supportano
MMX, non ricordo bene ma credo che si usasse un semplice "rep movs(b/w/
d)" o alla peggio un loop.
Saluti,
The Librarian
PS: Gentilmente non multipostare


Direi proprio di no. Per utilizzare DMA occorre che l' hardware supporti la
funzionalità, con segnali di hanshake etc.. cosa che e' costosa ed 
inutile da fare
per lavorare nella memoria dello stesso processore: oltretutto i canali DMA
sono risorse limitate che non puo' prendersi il primo tizo che vuole farsi
una copia di memoria..
Il DMA si usa (di solito) per scambiare dati tra un  processore ed una 
periferica
in una zona di memoria dedicata, utilizzando un controllore DMA (integrato o
meno nella CPU) il che scarica ovviamente la CPU dell' onere del 
trasferimento....
brix
 

nonSonomaEsisto ha scritto:

Sui PC-IBM compatibili, no di certo. L'architettura non ha canali DMA 
memoria-memoria ma solo memoria-I/O e viceversa.
Sotto un SO con memoria virtuale poi, occorre bloccare le pagine in RAM, 
  farsi dare l'indirizzo fisico di esse ed assicurarsi che siano 
fisicamente contigue (non è detto), prima di chiamare il DMA: in tutto 
fanno (almeno) cinque chiamate al SO con cambio di privilegio più due 
task switch. Se non sono contigue devi fartene assegnare di contigue 
oppure spostare quelle che hai (e addio al guadagno di tempo del DMA).
Ergo in genere non si usa il DMA per MEMCPY, e le volte che vale la pena 
non si usa MEMCPY ma lo si fa da soli.

 memoria-memoria ma solo memoria-I/O e viceversa.
Saranno passati 10 anni da quando giocavo con il DMA su x86 e quindi i
miei ricordi sono un po' fumosi, ma sono pressocche' certo che si
possa fare una copia memoria-memoria utilizzando due canali DMA (uno
in lettura e uno in scrittura).
Poi sul fatto che non abbia senzo utilizzarlo per memcpy sono
d'accordo.
Saluti,
The Librarian

ringrazio tutti per le risposte!
alla fine avete confermato quello che pensavo.
io ricordo quando utilizzavo il DMA anni fa su x86...
ora sto implementando dei buffer in c++
e sono abbastanza grandi (anche 200MB).
il fatto di copiare questi dati da una parte all'altra della memoria ed 
avere
il processore bloccato per fare una semplice copia lo trovo inefficiente...
oggi ho fatto alcune statistiche su sotto linux
e si arriva a circa 300 MB/s per la copia memoria memoria..
se metto altri processi alla fine si fa presto a raggiungere la saturazione
o comunque ad avere il processore bloccato per operazioni di semplice 
copiatura...
possibile che i progettisti di cpu non si siano inventati qualche istruzione 
a basso livello per
liberare il processore da questo fardello...!?!?

 liberare il processore da questo fardello...!?!?
E cosa si dovevano inventare? Tanto se lo fa la CPU deve comunque 
leggere di qua e scrivere di là. Per queste cose c'è appunto il DMA, 
forse dovresti vedere se riesci a usarlo lo stesso... altri meccanismi 
che possano aiutarti non ne vedo.
Magari dal lato software puoi inventarti qualcosa per non dover copiare 
tutta sta roba di qua e di là...
Una soluzione che mi viene in mente sarebbe usare la RAM grafica della 
scheda video, che è dual-port, e la GPU come processore generico. 
Informati su cosa può fare CUDA di Nvidia... io in queste cose sono un 
emerito ignorante.

 ha scritto nel messaggio 
news:HWHxj.178$Y83...@nntpserver.swip.net...

a complicare la questione c'è che
lavoro su sistemi embedded linux ...
anzi, non mi sono ancora state date le specifiche del sistema "reale".