C Singelthread schneller als Pthread?

[leboh]

ich habe sowas nicht, aber ich habe Zugriff auf solche lustigen Sachen, beruflich.
Der Core ist ein 2.2 Ghz SandyBridge-EP, also ein relativ nieder getakteter
der aktuellen Xeon Generation.

 

[kuddlmuddl]

singlethread: 77.7 Sekunden (ohne pthread, einfachst mögliches programm)

pthread 1 thread: 79 Sekunden

pthread 4 threads: 21.6 Sekunden
pthread 6 threads: 22.0 Sekunden
pthread 200 threads: 19.87 Sekunden

Das finde ich beides sehr komisch. Ein Thread starten kostet niemals 1 sec. Erst recht nicht wenn du unter Linux programmierst und pthread verwendest.. die sind ja ohne viel overhead direkt Teil des OS?

Vor allem da du mit 6 und mit 200 Threads noch Laufzeit sparst mal eine ganz naheliegende Vermutung:

Du startest dein Programm nicht mit der höchst möglichen Prozess-Priorität, oder?
Genau dann macht dieses Verhalten nämlich total Sinn. Das OS behandelt deine 200 Threads so wie ein anderes Programm wie nen VIrenscanner/Browser/mp3Player der evtl auch mal kurz Aufmerksamkeit möchte. Dh je mehr Threads du startest die auch alle auf Abarbeitung warten, desto größer ist die Chance dass der Scheduler einen davon ran lässt.
Durch max-prio sollte dieser Effekt verschwinden und mit so vielen Threads wie Cores (inkl HT) sollte es maximal sein. Doppelt so viele Threads wie Cores wird aber vermutlich keinen Messbaren Unterschied geben.

-pthread unterteilt den Integrationsinterval in kleine Teile, die jeweils von einem Thread bearbeitet werden, während bei cuda jeder Thread im gesament Interval [0,100] rumratet.

Das könnte ein weiterer Grund sein, wieso du mit mehr Threads als Cores an Performace gewinnst: Wenn ein Thread nur auf einem kleinen Überschaubaren Speicherbereich arbeitet hast du mehr Cache-Hits. Dh evtl passt dann alles in L1 oder später L2, Cache...
Um das vergleichbar zu machen müsste jeder Thread unabhängig von der Gesamtzahl der Threads immer auf den selben Daten arbeiten.

Nun macht es imho Sinn, dass pthread mit einem thread langsamer ist als die singlethread-Anwendung, da das pthread-Programm schlicht grösser ist, pthreads kreiert werden müssen, casts auf die Vektoren mit den Funktionsanweisungen usw. Die 2 Sekunden finde ich zwar etwas viel, aber würde ich jetzt nicht als krass beurteilen.

Langsamer als 1 Thread starten: ja. Messbar auf diese Art und Weise? Imho nein. Du misst in 100ms Einheiten (also 0,1 Sekudnen).. ein Thread starten wird nicht so lange dauern.
Sieht man auch an den 200 Threads: Diese zu starten und zu verwalten ist für einen modernen Prozessor und nen modernes OS mit wenig Zeitaufwand erledigt.

 

[maxwell-cs]

Das könnte ein weiterer Grund sein, wieso du mit mehr Threads als Cores an Performace gewinnst: Wenn ein Thread nur auf einem kleinen Überschaubaren Speicherbereich arbeitet hast du mehr Cache-Hits. Dh evtl passt dann alles in L1 oder später L2, Cache...
Um das vergleichbar zu machen müsste jeder Thread unabhängig von der Gesamtzahl der Threads immer auf den selben Daten arbeiten.

ich bezweifle, dass das hier ein grund ist (im allgemeinen natürlich schon!), da die "daten", auf denen gearbeitet wird, durch eine numerische funktion gegeben sind, die jedes mal neu ausgewertet wird.

 

[mahatma andi]

So, hab jetzt mal kurz nachgeschaut, wie das mit Prozessprioritäten unter Linux funktioniert und mein Programm mit unterschiedlichen Prioritäten starten lassen, wobei meine Befehle so aussehen:

sudo nice -n -20 ./pthread_integral

Das sollte also das Programm pthread_integral mit der höchstmöglichen Prozesspriorität starten, ändern tut das aber an der Zeit nichts, bzw. nicht signifikant , heisst, die Unterschiede bewegen sich in ein paar Zehntelsekunden, die auch bei gleicher Prozesspriorität als Schwankung auftreten. Sonstige Prozesse gibt es kaum, ausser Firefox und System Monitor. Der Linux-Desktop wird eigentlich rein zum Programmieren und Arbeiten benutzt.

Laut Callgrind müsste der 200-Threads-Prozess auch länger dauern, da er (absolut) mehr "kostet", was ich hier rauslesen würde:

Links ist der Prozess mit (in diesem Fall) 400 Threads, rechts mit vier.

Ergänzung (20. August 2012)

Hier noch ein Plot der Sekunden die die Berechnung dauert gegen die Anzahl Threads plotet:
https://dl.dropbox.com/u/25499038/nthreads_vs_time.png

Mittlerweilen habe ich das Programm noch so geändert, dass ich beim aufrufen die Anzahl threads bestimmen kann, e.g. ./pthread_integral 4 für 4 threads. Dann habe ich einfach in 2 For-Schleifen jede Threadzahl von 1 bis 20 neun mal durchlaufen lassen und den Computer sonst in Ruhe gelassen. Diesmal nur für 100 Millionen Berechnungen, damits nicht ewig lang geht und nunja... sieht nicht so aus, als ob sich über 4 Threads gross was ändern würde. Die durchgezogene Linie ist etwa der Wert bei 14 und soll dem Vergleich dienen, ist also kein fit.