Scalabilità di applicazioni multithread su macchine multicore

Question

Sto lavorando a un progetto in cui abbiamo bisogno di più prestazioni.Nel corso del tempo abbiamo continuato a evolvere il design per lavorare maggiormente in parallelo (sia threaded che distribuiti).Quindi l'ultimo passo è stato spostarne una parte su una nuova macchina con 16 core.Sto scoprendo che dobbiamo ripensare il modo in cui facciamo le cose per scalare così tanti core in un modello di memoria condivisa.Ad esempio, l'allocatore di memoria standard non è abbastanza buono.

Quali risorse consiglierebbero le persone?

Finora ho trovato l'articolo di Sutter Dr.Dobbs sarà un buon inizio.Ho appena ricevuto The Art of Multiprocessor Programming e il libro The O'Reilly su Intel Threading Building Blocks

Answer 1

Un paio di altri libri che potrebbero esserti utili sono:

• Algoritmi di sincronizzazione e programmazione concorrente
• Modelli per la programmazione parallela
• Comunicazione di processi sequenziali di C.UN.R.Hoare (un PDF classico e gratuito a quel link)

Inoltre, considera di fare meno affidamento sulla condivisione dello stato tra processi simultanei.Ridimensionerai molto, molto meglio se puoi evitarlo perché sarai in grado di suddividere unità di lavoro indipendenti senza dover fare molta sincronizzazione tra di loro.

Anche se è necessario condividere uno stato, vedere se è possibile suddividere lo stato condiviso dall'elaborazione effettiva.Ciò ti consentirà di eseguire la maggior parte dell'elaborazione in parallelo, indipendentemente dall'integrazione delle unità di lavoro completate nello stato condiviso.Ovviamente questo non funziona se ci sono dipendenze tra unità di lavoro, ma vale la pena indagare invece di dare per scontato che lo stato sarà sempre condiviso.

Answer 2

Potresti voler dare un'occhiata Strumenti per le prestazioni di Google.Hanno rilasciato la loro versione di malloc che utilizzano per applicazioni multi-thread.Include anche un bel set di strumenti di profilazione.

Answer 3

Jeffrey Richter adora molto il threading.Ha alcuni capitoli sul threading nei suoi libri e controlla il suo blog:

http://www.wintellect.com/cs/blogs/jeffreyr/default.aspx.

Answer 4

Come direbbe Monty Python "e ora qualcosa di completamente diverso" - potresti provare un linguaggio/ambiente che non utilizza thread, ma processi e messaggistica (nessuno stato condiviso).Uno dei più maturi è Erlang (e questo libro eccellente e divertente: http://www.pragprog.com/titles/jaerlang/programming-erlang).Potrebbe non essere esattamente rilevante per le tue circostanze, ma puoi comunque imparare molte idee che potresti applicare in altri strumenti.

Per altri ambienti:

.Net ha F# (per imparare la programmazione funzionale).JVM ha Scala (che ha attori, molto simili a Erlang, ed è un linguaggio ibrido funzionale).Inoltre c'è il framework "fork join" di Doug Lea per Java che fa gran parte del duro lavoro per te.

Answer 5

L'allocatore in FreeBSD ha recentemente ricevuto un aggiornamento per FreeBSD 7.Si chiama quello nuovo jemaloc ed è apparentemente molto più scalabile rispetto a più thread.

Non hai menzionato quale piattaforma stai utilizzando, quindi forse questo allocatore è a tua disposizione.(Credo Firefox 3 utilizza jemalloc, anche su Windows.Quindi i porti devono esistere da qualche parte.)

Answer 6

Dare un'occhiata a Tesoro se stai eseguendo molta allocazione di memoria.

Tira il tuo Blocca elenco gratuito.Una buona risorsa è qui: è in C# ma le idee sono portabili.Una volta che ti abitui a come funzionano, inizi a vedere altri posti in cui possono essere utilizzati e non solo negli elenchi.

Answer 7

Prima o poi dovrò dare un'occhiata a Hoard, Google Perftools e jemalloc.Per ora utilizziamo scalable_malloc di Intel Threading Building Blocks e funziona abbastanza bene.

Nel bene e nel male, utilizziamo C++ su Windows, anche se gran parte del nostro codice verrà compilato perfettamente con gcc.A meno che non ci sia una ragione convincente per passare a RedHat (la principale distribuzione Linux che usiamo), dubito che valga la pena di spostarsi.

Mi piacerebbe usare Erlang, ma qui c'è molto da rifare adesso.Se pensiamo ai requisiti per lo sviluppo di Erlang in un contesto di telecomunicazioni, sono molto simili al nostro mondo (commercio elettronico).Il libro di Armstrong è nella mia pila di lettura :)

Nei miei test per passare da 4 core a 16 core ho imparato ad apprezzare il costo di qualsiasi blocco/contesa nella parte parallela del codice.Fortunatamente abbiamo una grande porzione che si adatta ai dati, ma anche questo all'inizio non ha funzionato a causa di un blocco aggiuntivo e dell'allocatore di memoria.

Answer 8

Mantengo un blog sui collegamenti di concorrenza che potrebbe essere di interesse continuo:

http://concurrency.tumblr.com