2009-11-12 11 views
8

Ho bisogno di migliorare il throughput del sistema.Come utilizzare l'output cachegrind per ottimizzare l'applicazione

Il normale ciclo di ottimizzazione è stato fatto e abbiamo già ottenuto un throughput migliore di 1,5 volte.

Ora sto iniziando a chiedermi se posso utilizzare l'output cachegrind per migliorare il throughput del sistema.

Qualcuno può indicarmi come iniziare su questo?

Quello che capisco è che dobbiamo assicurare che i dati più frequentemente usati siano mantenuti abbastanza piccoli in modo che rimangano nella cache L1 e che il successivo set di dati si adatti alla L2.

È questa la direzione giusta che sto prendendo?

risposta

6

È vero che l'output cachegrind di per sé non fornisce troppe informazioni su come ottimizzare l'ottimizzazione del codice. Uno ha bisogno di sapere come interpretarlo e quello che stai dicendo sull'adattamento dei dati in L1 e L2 è davvero la giusta direzione.

Per comprendere appieno il modo in cui i modelli di accesso alla memoria influenzano le prestazioni, consiglio di leggere un eccellente documento "What Every Programmer Should Know About Memory" di Ulrich Drepper, il manutentore di GNU libc.

+0

Grazie Kaustaurya, quello era davvero un articolo eccellente. Ricordo di aver letto prima questo articolo ma stavolta ho potuto apprezzare molto meglio le impressioni. – rajeshnair

2

Secondo the Cachegrind documentation, i dettagli forniti da cachegrind sono il numero di errori di cache per una determinata parte del codice. Devi sapere come funzionano le cache sull'architettura che stai mirando in modo da sapere come risolvere il codice. In pratica, ciò significa rendere i dati più piccoli o modificare il modello di accesso di alcuni dati in modo che i dati memorizzati nella cache siano ancora nella cache. Tuttavia, è necessario comprendere i dati e l'accesso ai dati del programma prima di poter agire sulle informazioni. Come si dice nel manuale,

Insomma, Cachegrind posso dirvi dove alcuni dei colli di bottiglia nel codice sono, ma non si può dire come risolverli. Devi farlo da solo. Ma almeno hai le informazioni!

3

Se si riscontrano problemi nell'analisi dell'output di cachegrind, esaminare KCacheGrind (dovrebbe essere disponibile nella distro di scelta). Lo uso e lo trovo molto utile.

2

1.5x è una bella accelerazione. Significa che hai trovato qualcosa che ti è costato il 33% del tempo di cui potresti liberarti. Scommetto che puoi fare di più, anche prima di scendere a problemi di basso livello come la memoria cache dei dati. This is an example of how. Fondamentalmente, potresti avere ulteriori problemi di prestazioni (e opportunità di accelerazione) che prima non erano grandi, come dice il 25%. Bene, con l'accelerazione 1,5x, quel 25% è ora del 37,5%, quindi è "vale più" di quanto non fosse. Spesso tale problema si presenta sotto forma di una chiamata di funzione mid-stack che richiede un lavoro che, una volta che sai quanto costa, puoi decidere che non è completamente necessario. Poiché kcachegrind in realtà non li individua, potresti non rendertene conto che è un problema.

+0

Sono per lo più d'accordo. Tuttavia, non considererei la cache un problema di basso livello. Qualunque piattaforma che potresti avere come target avrà una cache (anche le moderne carte CUDA). Anche l'ottimizzazione per la cache potrebbe produrre grandi miglioramenti e può essere eseguita senza guardare l'output dell'assembly dal compilatore. –

+0

@ JørgenFogh: Giusto. Gli sviluppatori del processore hanno fatto tutto il possibile nel loro dominio per ottimizzare i tempi di elaborazione. Noi sviluppatori di software non sempre ricambiamo garantendo che il nostro codice sia "snello e cattivo".Lo vedo tutto il tempo. –

+0

Questo è assolutamente vero. Il mio punto è che non c'è modo che un buon processore possa compensare un algoritmo inefficiente. Ciò include algoritmi con prestazioni cache scadenti. L'efficienza della cache non può essere aggiunta come ripensamento. –