Mise à l'échelle d'applications multithread sur des machines multicœurs

Question

Je travaille sur un projet où nous avons besoin de plus de performances.Au fil du temps, nous avons continué à faire évoluer la conception pour fonctionner davantage en parallèle (à la fois threadés et distribués).La dernière étape a ensuite été d'en déplacer une partie sur une nouvelle machine à 16 cœurs.Je trouve que nous devons repenser la façon dont nous faisons les choses pour évoluer vers autant de cœurs dans un modèle de mémoire partagée.Par exemple, l'allocateur de mémoire standard n'est pas suffisant.

Quelles ressources les gens recommanderaient-ils ?

Jusqu'à présent, j'ai trouvé la chronique de Sutter, Dr.Dobbs est un bon début.Je viens de recevoir The Art of Multiprocessor Programming et The O'Reilly book sur les blocs de construction Intel Threading.

Answer 1

Voici quelques autres livres qui vous seront utiles :

• Algorithmes de synchronisation et programmation simultanée
• Modèles pour la programmation parallèle
• Communiquer des processus séquentiels par C.UN.R.Hoare (un PDF classique et gratuit sur ce lien)

Pensez également à moins vous fier au partage d’état entre des processus simultanés.Vous évoluerez bien mieux si vous pouvez l'éviter, car vous pourrez répartir des unités de travail indépendantes sans avoir à effectuer autant de synchronisation entre elles.

Même si vous devez partager un état, voyez si vous pouvez séparer l'état partagé du traitement réel.Cela vous permettra d'effectuer un maximum de traitements en parallèle, indépendamment de la réintégration des unités de travail terminées dans l'état partagé.Évidemment, cela ne fonctionne pas si vous avez des dépendances entre les unités de travail, mais cela vaut la peine d'enquêter au lieu de simplement supposer que l'état sera toujours partagé.

Answer 2

Vous voudrez peut-être vérifier Outils de performances de Google.Ils ont publié leur version de malloc qu'ils utilisent pour les applications multithread.Il comprend également un bel ensemble d’outils de profilage.

Answer 3

Jeffrey Richter aime beaucoup le threading.Il a quelques chapitres sur le filetage dans ses livres et consultez son blog :

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

Answer 4

Comme dirait Monty Python "et maintenant pour quelque chose de complètement différent" - vous pouvez essayer un langage/environnement qui n'utilise pas de threads, mais des processus et des messages (pas d'état partagé).L'un des plus matures est l'erlang (et ce livre excellent et amusant : http://www.pragprog.com/titles/jaerlang/programming-erlang).Cela ne correspond peut-être pas exactement à votre situation, mais vous pouvez quand même apprendre de nombreuses idées que vous pourrez peut-être appliquer dans d'autres outils.

Pour les autres environnements :

.Net a F# (pour apprendre la programmation fonctionnelle).JVM a Scala (qui a des acteurs, un peu comme Erlang, et est un langage hybride fonctionnel).Il existe également le framework "fork join" de Doug Lea pour Java qui fait une grande partie du travail à votre place.

Answer 5

L'allocateur de FreeBSD a récemment reçu une mise à jour pour FreeBSD 7.Le nouveau s'appelle jemaloc et est apparemment beaucoup plus évolutif en ce qui concerne plusieurs threads.

Vous n'avez pas mentionné la plate-forme que vous utilisez, alors peut-être que cet allocateur est à votre disposition.(Je crois Firefox 3 utilise jemalloc, même sur Windows.Les ports doivent donc exister quelque part.)

Answer 6

Jeter un coup d'œil à Magot si vous effectuez beaucoup d'allocation de mémoire.

Roulez le vôtre Verrouiller la liste gratuite.Une bonne ressource est ici – elle est en C# mais les idées sont portables.Une fois que vous vous êtes habitué à leur fonctionnement, vous commencez à voir d'autres endroits où ils peuvent être utilisés et pas seulement dans des listes.

Answer 7

Je devrai consulter Hoard, Google Perftools et jemalloc un jour.Pour l'instant, nous utilisons scalable_malloc d'Intel Threading Building Blocks et il fonctionne assez bien.

Pour le meilleur ou pour le pire, nous utilisons C++ sous Windows, même si une grande partie de notre code se compilera très bien avec gcc.À moins qu'il n'y ait une raison impérieuse de passer à Redhat (la principale distribution Linux que nous utilisons), je doute que cela vaille la peine de déménager.

J'adorerais utiliser Erlang, mais il y a beaucoup trop de choses ici pour le refaire maintenant.Si l’on réfléchit aux exigences liées au développement d’Erlang dans le contexte des télécommunications, elles sont très similaires à celles de notre monde (commerce électronique).Le livre d'Armstrong est sur ma pile à lire :)

Lors de mes tests visant à passer de 4 cœurs à 16 cœurs, j'ai appris à apprécier le coût de tout verrouillage/conflit dans la partie parallèle du code.Heureusement, nous avons une grande partie qui évolue avec les données, mais même cela n'a pas fonctionné au début à cause d'un verrou supplémentaire et de l'allocateur de mémoire.

Answer 8

Je maintiens un blog de liens de concurrence qui peut présenter un intérêt continu :

http://concurrency.tumblr.com