Skalieren von Multithread-Anwendungen auf mehrkernigen Maschinen

Question

Ich arbeite an einem Projekt, wo wir mehr Leistung benötigen. Im Laufe der Zeit haben wir das Design weiterentwickelt, um mehr parallel (sowohl mit Threads als auch mit verteilten) zu arbeiten. Der letzte Schritt bestand darin, einen Teil davon auf eine neue Maschine mit 16 Kernen zu übertragen. Ich stelle fest, dass wir neu überdenken müssen, wie wir Dinge auf diese vielen Kerne in einem gemeinsamen Speichermodell skalieren können. Zum Beispiel ist der Standardspeicherzuordner nicht gut genug.

Welche Ressourcen würden die Leute empfehlen?

Bis jetzt habe ich Sutters Spalte Dr. Dobbs gefunden, um ein guter Anfang zu sein. Ich habe gerade die Kunst der Multiprozessor-Programmierung und das O'Reilly-Buch über Intel Threading Building Blocks

Answer 1

Ein paar andere Bücher, die hilfreich sein werden, sind:

• Synchronization Algorithms and Concurrent Programming
• Patterns for Parallel Programming
• Communicating Sequential Processes von CAR Hoare (ein klassisches, kostenloses PDF unter diesem Link)

Auch, in Betracht ziehen, sich weniger auf das Teilen des Status zwischen concu zu verlassen rnt Prozesse. Sie werden viel besser skalieren, wenn Sie es vermeiden können, weil Sie in der Lage sind, unabhängige Arbeitseinheiten zu verteilen, ohne dass Sie so viel synchronisieren müssen.

Auch wenn Sie einige Status freigeben müssen, prüfen Sie, ob Sie den freigegebenen Status von der tatsächlichen Verarbeitung partitionieren können. Auf diese Weise können Sie die Verarbeitung parallel durchführen, unabhängig von der Integration der abgeschlossenen Arbeitseinheiten in den gemeinsamen Status. Offensichtlich funktioniert das nicht, wenn Sie Abhängigkeiten zwischen den Arbeitseinheiten haben, aber es lohnt sich zu untersuchen, anstatt nur davon auszugehen, dass der Status immer geteilt wird.

Answer 2

Sie möchten vielleicht überprüfen, Google's Performance Tools. Sie haben ihre Version von malloc veröffentlicht, die sie für Multithread-Anwendungen verwenden. Es enthält auch eine schöne Reihe von Profiling-Tools.

Answer 3

Jeffrey Richter hat viel zu tun. Er hat ein paar Kapitel über Threading in seinen Büchern und in seinem Blog:

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

Answer 4

Der Allokator in FreeBSD hat vor kurzem ein Update für FreeBSD 7 bekommen. Der neue heißt jemaloc und ist anscheinend viel mehr skalierbar in Bezug auf mehrere Threads.

Sie haben nicht erwähnt, welche Plattform Sie verwenden, daher steht Ihnen dieser Allokator möglicherweise zur Verfügung. (Ich glaube, Firefox 3 uses jemalloc, auch auf Windows So Ports irgendwo vorhanden sein müssen..)

Answer 5

Da monty python sagen würde "und jetzt für etwas ganz anderes" - könnten Sie eine Sprache/Umgebung ausprobieren, die keine Threads, sondern Prozesse und Messaging verwendet (kein gemeinsamer Status). Einer der ausgereiftesten ist Erlang (und dieses ausgezeichnete und lustige Buch: http://www.pragprog.com/titles/jaerlang/programming-erlang). Ist vielleicht nicht genau relevant für Ihre Situation, aber Sie können immer noch viele Ideen lernen, die Sie möglicherweise in anderen Tools anwenden können.

Für andere Umgebungen:

.Net hat F # (funktionale Programmierung zu lernen). JVM hat Scala (die Schauspieler hat, sehr ähnlich wie Erlang, und ist funktionale hybride Sprache).Außerdem gibt es das "fork join" -Framework von Doug Lea für Java, das dir viel Arbeit abnimmt.

Answer 6

Werfen Sie einen Blick auf Hoard, wenn Sie eine Menge Speicherzuweisung machen.

Rollen Sie Ihre eigenen Lock Free List. Eine gute Ressource ist hier - es ist in C#, aber die Ideen sind tragbar. Sobald Sie sich daran gewöhnt haben, wie sie funktionieren, sehen Sie andere Orte, an denen sie verwendet werden können, und nicht nur in Listen.

Answer 7

Ich werde irgendwann Hoard, Google Pertools und jemalloc auschecken müssen. Momentan verwenden wir scalable_malloc von Intel Threading Building Blocks und es funktioniert gut genug.

Ob gut oder schlecht, wir verwenden C++ unter Windows, obwohl ein großer Teil unseres Codes mit gcc kompiliert wird. Wenn es keinen zwingenden Grund gibt, zu redhat zu wechseln (die wichtigste Linux-Distribution, die wir verwenden), bezweifle ich, dass es sich lohnt, die Kopfschmerzen/politischen Schwierigkeiten zu überwinden.

Ich würde gerne Erlang verwenden, aber es gibt viel zu tun, um es jetzt zu wiederholen. Wenn wir über die Anforderungen an die Entwicklung von Erlang in einem Telco-Umfeld nachdenken, sind sie unserer Welt (elektronischer Handel) sehr ähnlich. Armstrongs Buch ist auf meinem Stack zu lesen :)

In meinen Tests von 4 Kernen auf 16 Kerne zu skalieren habe ich gelernt, die Kosten für jede Sperre/Konkurrenz im parallelen Teil des Codes zu schätzen. Glücklicherweise haben wir einen großen Teil, der mit den Daten skaliert, aber selbst das hat aufgrund einer zusätzlichen Sperre und des Speicherzuordners nicht funktioniert.

Answer 8

ich pflegen eine Gleichzeitigkeit Link Blog, das von laufenden Interesse sein können:

http://concurrency.tumblr.com