Kein Gewinn durch ein paar pthreads auf einem AMD-Prozessor?

Question

Ich habe gerade einen neuen 16-Core-Server mit AMD 6212-Prozessoren bekommen. Ich habe Code, den ich auch auf einer Vielzahl von Intel-Prozessoren ausgeführt habe. Er verwendet gesperrte Warteschlangen, um die Arbeit an pthreads zu verteilen, die dann die Arbeit zurück in den gemeinsamen Speicher schreiben, wobei auch die Schreibvorgänge gesperrt sind. Ich bin primär rechengebunden.

Bei Intel-Prozessoren steigt die Leistung sofort, wenn ich die Anzahl der Threads erhöhe. Wenn ich von 1 auf 2 Threads gehe, verdoppelt sich die Leistung fast.

Mit demselben Code auf den AMD-Prozessoren erhalte ich auch mit 4 Threads keinen Gewinn (eine leichte Verlangsamung). Aber wenn ich 128 Threads verwende, sehe ich einen 6-fachen Geschwindigkeitszuwachs.

Hat jemand eine Idee, woran das liegen könnte?

Was die Spezifikationen des Betriebssystems betrifft, so tippe ich:

cat /proc/version

Ich verstehe:

Linux version 2.6.32-5-amd64 (Debian 2.6.32-39) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Thu Nov 3 03:41:26 UTC 2011

Answer 1

Meine erste Vermutung ist, dass der Linux Scheduler Ihre Threads nicht auf separate Kerne verteilt hat.

Der Linux-Scheduler versucht sehr schwer Aufgaben auf der zuletzt verwendeten CPU zu belassen, so dass der Cache die besten Chancen hat, relevante und nützliche Daten oder Anweisungen zu enthalten. Ich habe festgestellt, dass dies nicht der Fall ist. (Ich weiß, ich habe sogar Code gesehen, der behauptet, die Neuverteilung vorzunehmen, aber ich habe CPU-intensive Arbeitslasten entdeckt, die alle auf demselben Geschwisterprozessor laufen, ohne jemals auf einen anderen Kern zu wechseln).

Verwendet Ihr Code taskset(1) , sched_setaffinity(2) oder die cpuset(7) Mechanismus zur manuell die rechenintensiven Aufgaben auf alle Prozessoren zu verteilen? Wenn nicht, schlage ich vor, Folgendes zu versuchen taskset(1) zunächst von Hand, um zu sehen, ob sich der Durchsatz verbessert, und einschließlich sched_setaffinity(2) in Ihr Programm aufnehmen, wenn Sie die erwarteten Verbesserungen sehen.

Answer 2

Das Problem ist also noch nicht zu 100 % gelöst, aber es scheint, dass das Problem mit dem Speicherzugriff zusammenhängt. Der Code hat während des größten Teils der Ausführung keine dynamische Speicherzuweisung, aber die Threads wiesen beim Start etwa 100 kleine Speicherstücke auf dem Heap zu. In kleinen Beispielversionen des Programms konnte ich die Engpässe beseitigen, indem ich den Speicher für jeden Thread auf dem Stack statt auf dem Heap zuordnete.

Ohne zu sehr auf die Architektur einzugehen, hat es den Anschein, dass der zugewiesene Speicher verschachtelt wurde, so dass sich die verschiedenen Threads denselben Speicher teilten, wodurch die parallele Leistung beeinträchtigt wurde.