Programmazione parallela - C

Real Life
41
ma sul wiki linkato non c'erano? ci sono quelli che sfruttano le giunzioni, quelli che usando direttamente effetti quantistici e quelli che sfruttano il rumore termico delle resistenze

va che bel bussolotto
http://qrbg.irb.hr/
42
Bhe, quello che ho linkato io sfrutta il tunneling quantistico degli elettroni in una giunzione P-N con bias inverso. Quasi quasi me la compro...
Comunque io intendevo proprio i nomi commerciali.
43
Vado di fretta e non ho letto se qualcuno ha gia' risposto a questo, ma:



C salva i vettori in row major.
44
Ah se vogliamo parlare di accessi alla memoria, non posso non citare il famoso documento di Drepper, pubblicato anche a puntate su LWN - http://people.redhat.com/drepper/cpumemory.pdf
Come non-informatico mi ha impressionato molto.
45


Premettendo che è interessante, ma 114 pagine al momento non mi sono affrontabili, di che parla precisamente? Di come funzionano le memorie a livello hardware?
46
Porca vacca Drepper

Peccato sia uno stronzo come pochi
47
non conoscete il Dice-O-Matic?

48


Anche, ma non in modo fine a se stesso. Tutto il documento è sostanzialmente costruito sull'idea di spiegare come la struttura del sotto-sistema di memorizzazione (RAM e cache) influenzi le prestazioni di un programma a seconda di come questo decida di gestire i dati.

Un'esempio relativamente semplice, che mi aveva impressionato molto, era quello dove veniva mostrato come sia più veloce moltiplicare due matrici facendo prima la trasposta di una e poi procedendo riga per riga, piuttosto che operando il prodotto da definizione riga per colonna (sezione 6.2.1).
49
che figata il dice-o-matic
50


now, this is cool!
51


Eh è questo il punto. I dati contigui vengono caricati quando il compilatore sa dividere le varie celle del vettore. Ti ho un esempio, considera;

ex1:
int c[4][5];

ex2:
int *c;
c = (int *)malloc(sizeof(int)*4*5);

nell'esempio 2 lui alloca la giusta regione ma non ha una divisione tra righe e colonne, devo essere io a calcolare il giusto offsett di volta in volta quando voglio un elemento (ecco da dove esce la macro). Il problema è appunto che il compilatore, non avendo la spaziatura del vettore, non alloca gli elementi "contigui", ed il programma perde un sacco in velocità.

Ll.
52


Ahumm non sono del tutto sicuro che questo sia esatto... credo proprio che malloc garantisca la contiguita' della memoria allocata (altrimenti fare il traversal di un vettore allocato con malloc fallirebbe miseramente), quindi il problema non dovrebbe porsi. Hai provato a scrivere un programmino di test che misura il tempo impiegato a, chesso', moltiplicare due matrici 1000X1000 50 volte nei vari casi per avere un riscontro pratico?
53
malloc alloca uno spazio di memoria contiguo. Con la dicitura [][] viene "spiegato" come accedere alla locazione di memoria esatta. Chiaramente se si scrive in C, l'accesso a dati contigui sarà per righe e seguirà l'aritmetica dei puntatori. Se si accede per colonne il compilatore deve fare "grossi salti" tra aree di memoria. Il vero problema sono gli effetti negativi di caching che non si possono controllare

Provate a fare verificare il tempo impiegato a fare queste due porzioni di codice

for (int i=0; i< 10000; i++){ for(int j=0; j< 10000; j++) { a[i][j] += 1.0; } }

for (int j=0; j< 10000; j++){ for(int i=0; i< 10000; i++) { a[i][j] += 1.0; } }


E comunque il calcolo parallelo SPACCA!