Sto eseguendo un esperimento di accesso alla memoria in cui è stata utilizzata una matrice 2D con ogni riga delle dimensioni di una pagina di memoria. L'esperimento consiste nel leggere ogni elemento usando la riga/colonna principale e poi anche scrivere su ogni elemento usando la riga/colonna maggiore. La matrice a cui si accede è stata dichiarata con ambito globale per facilitare i requisiti di programmazione.Sta leggendo uno "zero" dalla memoria più velocemente della lettura di altri valori?
Il punto di questa domanda è che con la matrice di test dichiarata staticamente, i valori sono inizializzati a zero dal compilatore ei risultati che ho trovato erano piuttosto interessanti. Quando ho letto le operazioni di prima, vale a dire
rowMajor_read();
colMajor_read();
rowMajor_write();
colMajor_write();
Quindi la mia operazione colMajor_read finito molto in fretta. 
Tuttavia, se faccio le operazioni di scrittura prima della lettura che abbiamo:
rowMajor_write();
colMajor_write();
rowMajor_read();
colMajor_read();
E l'operazione di lettura column-major è aumentato di quasi un ordine di grandezza.
Ho pensato che deve avere qualcosa a che fare con il modo in cui il compilatore ottimizza il codice. Poiché la matrice globale era identicamente zero per ogni elemento, il compilatore ha rimosso completamente le operazioni di lettura? O è in qualche modo "più facile" leggere un valore dalla memoria che è identicamente zero?
Non si passano comandi speciali del compilatore per quanto riguarda le ottimizzazioni, ma ho dichiarato le mie funzioni in questo modo.
inline void colMajor_read(){
register int row, col;
register volatile char temp __attribute__((unused));
for(col = 0; col < COL_COUNT; col++)
for(row = 0; row < ROW_COUNT; row++)
temp = testArray[row][col];
}
Perché ero in esecuzione in questioni in cui il compilatore completamente rimossa la variabile temp dalla funzione di cui sopra in quanto non è mai stato utilizzato. Penso che avere sia volatile sia __attribute__((unused)) sia ridondante, ma l'ho incluso comunque. Ho avuto l'impressione che non siano state implementate ottimizzazioni su una variabile volatile.
Qualche idea?
Ho esaminato l'assieme generato ei risultati sono identici per la funzione colMajor_read. La versione non in linea (assemblaggio): http://pastebin.com/C8062fYB
La mia ipotesi è con la cache di sistema e la previsione. – Nit
Concordo con @Nit. La località cache è molto probabilmente la fonte della varianza. Le cache possono facilmente dare un miglioramento del tempo di accesso 10x. Se si sospetta seriamente che il compilatore ottimizzi le operazioni di trasferimento (improbabile attraverso le funzioni, ma non strettamente impossibile), ottenere un output assembler delle funzioni C da verificare. –
Aspetta ragazzi. Non penso che sia tutto così complicato. Poiché i metodi sono in linea, ciò significa che tutte queste funzioni si trovano all'interno della stessa unità di compilazione, quindi il compilatore può fare cose fantastiche. Principalmente, può dire se hai cambiato o meno la variabile dal momento della lettura e della scrittura, quindi potrebbe facilmente reinterpretare il codice come 'temp = 0;' che sarebbe pazzesco velocemente al confronto. Puoi pubblicare l'assemblea? – IdeaHat