Scalarea aplicațiilor multithreaded pe mașini multicore

Lucrez la un proiect dacă avem nevoie de mai multă performanță. Cu timpul am continuat să dezvoltăm designul pentru a lucra mai mult în paralel (atât filetate cât și distribuite). Ultimul pas a fost să mutați o parte dintr-o mașină nouă cu 16 nuclee. Am constatat că trebuie să regândim modul în care facem lucrurile pe scară largă la numeroasele nuclee dintr-un model de memorie partajată. De exemplu, alocatorul de memorie standard nu este suficient de bun.

Ce resurse ar recomanda oamenii?

Până acum am găsit coloana lui Sutter Dr. Dobbs să fie un început bun. Tocmai am primit The Art of Multiprocessor Programming și cartea O'Reilly despre blocurile de structură cu filet Intel

0
fr hi bn

8 răspunsuri

Aruncați o privire la Hoard dacă faceți o mulțime de alocare a memoriei.

Rulați propriul Blocare listă liberă . O resursă bună este aici - este în C# dar ideile sunt portabile. Odată ce vă obișnuiți cu modul în care lucrează, începeți să vedeți alte locuri în care pot fi utilizate și nu doar în liste.

0
adăugat

Pe măsură ce monty python ar spune "și acum pentru ceva complet diferit" - ați putea încerca un limbaj / mediu care nu utilizează fire, ci procese și mesagerie (fără starea comună). Unul dintre cei mai maturi este erlang (și această carte excelentă și distractivă: http: // www.pragprog.com/titles/jaerlang/programming-erlang ). Nu poate fi exact relevant pentru circumstanțele dvs., dar puteți învăța în continuare o mulțime de idei pe care ați putea să le aplicați în alte instrumente.

Pentru alte medii:

.Net are F # (pentru a învăța programarea funcțională). JVM are Scala (care are actori, foarte asemănător cu Erlang și este un limbaj hibrid funcțional). Există, de asemenea, cadrul "fork join" de la Doug Lea pentru Java, care face mult efort pentru tine.

0
adăugat

Alocatorul din FreeBSD a primit recent o actualizare pentru FreeBSD 7. Cel nou este numit jemaloc și se pare că este mult mai scalabilă în ceea ce privește firele multiple.

Nu ați menționat ce platformă utilizați, deci poate că acest alocator este disponibil pentru dvs. (Cred că Firefox 3 utilizează jemalloc , chiar și pe ferestre. Deci porturile trebuie să existe undeva.)

0
adăugat

Va trebui să fac check-out Hoard, Google Perftools și jemalloc cândva. Deocamdată, folosim scalable_malloc de la Intel Threading Building Blocks și funcționează destul de bine.

Pentru mai bine sau mai rău, folosim C ++ pe Windows, deși o mare parte din codul nostru se va compila cu gcc foarte bine. Dacă nu există un motiv convingător pentru a vă deplasa la redhat (linia principală de distribuție pe care o folosim), mă îndoiesc că merită durerea de cap / probleme politice să se miște.

Mi-ar plăcea să-l folosesc pe Erlang, dar există multe modalități de a face acest lucru acum. Dacă ne gândim la cerințele legate de dezvoltarea Erlang într-un cadru telefonic, acestea sunt foarte asemănătoare cu lumea noastră (comerțul electronic). Cartea lui Armstrong este pe mine pentru a citi stiva :)

În încercarea mea de a scala de la 4 nuclee la 16 nuclee, am învățat să apreciez costul oricărei blocări / controverse din partea paralelă a codului. Din fericire avem o porțiune mare care se scaldă cu datele, dar chiar și asta nu a funcționat la început din cauza unei blocări suplimentare și a alocatorului de memorie.

0
adăugat

Jeffrey Richter are multe fire. El are câteva capitole despre filetarea cărților sale și a verifica blogul său:

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

0
adăugat

Câteva alte cărți care vor fi de ajutor sunt:

De asemenea, luați în considerare utilizarea mai puțin pe partajarea stării între procesele concurente. Veți scala mult, mult mai bine dacă o puteți evita pentru că veți putea să împărțiți unitățile independente de lucru fără a fi nevoie să efectuați o sincronizare între ele.

Chiar dacă aveți nevoie să împărtășiți o anumită stare, vedeți dacă puteți împărți starea partajată din procesarea reală. Acest lucru vă va permite să faceți cât mai mult din procesare în paralel, independent de integrarea unităților completate de muncă înapoi în starea comună. Evident, acest lucru nu funcționează dacă aveți dependențe între unitățile de lucru, însă merită investigat în loc să presupunem că statul va fi mereu împărtășit.

0
adăugat

Mă mențin un blog de legătură concurente care poate fi de interes permanent:

http://concurrency.tumblr.com

0
adăugat

Poate doriți să consultați Instrumentele de performanță Google . Au lansat versiunea lor de malloc pe care o folosesc pentru aplicații cu mai multe filete. De asemenea, include un set frumos de instrumente de profilare.

0
adăugat