Wieviele threads?

[jabaduu]

Moin, es heisst ja immer bei einem n Core Processor ist es am effizientesten n+1 threads zu benutzen. Aber was ist, wenn andere Leute das Programm auch benutzen sollen? Bietet man dann verschiedene Versionen für verschiedene Prozessoren an?

 

[mrBrown]

Moin, es heisst ja immer bei einem n Core Processor ist es am effizientesten n+1 threads zu benutzen.

Wo heißt es das?

Aber was ist, wenn andere Leute das Programm auch benutzen sollen? Bietet man dann verschiedene Versionen für verschiedene Prozessoren an?

In Java? Nein.
Wenn du strikt "n Kerne = n+1 Threads" befolgen willst, dann kannst du in Java einfach die Anzahl an Kernen abfragen und entsprechend viele Threads starten.

 

[jabaduu]

quelle stackoverflow + google

 

[jabaduu]

Danke. Wusste gar nicht, dass das so geht.

 

[mrBrown]

quelle stackoverflow + google

Diese Genauigkeit und Präzision ist echt unglaublich.

 

[httpdigest]

es heisst ja immer bei einem n Core Processor ist es am effizientesten n+1 threads zu benutzen

Schwachsinn.

Wieviele Threads für ein bestimmtes Problem optimal sind, hängt nicht von der Anzahl der Prozessoren ab, sondern von dem Problem. Bist du ALU-bound oder I/O-bound? Kannst du mehrere unabhängige Funktionen/Teile deines Algorithmus parallel laufen lassen ("functional parallelism") oder kannst du Parallelisierung über die Daten vornehmen ("data parallelism")? Außerdem ist der Parallelisierungsgrad deines Problems wichtig, siehe Amdahl's Law: https://en.wikipedia.org/wiki/Amdahl's_law, bzw. wie sehr Threads untereinander kommunizieren müssen.
Desweiteren ist wichtig, wie viel "Cache Trashing" dein Algorithmus betreibt und wie häufig unterschiedliche Threads dasselbe Datum bzw. dieselbe Cache Line im Speicher schreiben - da zumindest die x86-Familie Coherent Caching verwendet, also alle Prozessoren sehen immer denselben Speicherinhalt und müssen ihre Cache-Transaktionen untereinander austauschen, um das sicherzustellen.

 

[jabaduu]

ok httpdigest ich bin bei der suche über anzahl core und threads wohl in ein Unix Forum gekommen.
(Liegt wohl an meiner Migräne, liege seit 30 Stunden in einem abgedunkelten Raum mit höllische Kopfschm)
https://unix.stackexchange.com/ques...reads-makes-it-slower-than-using-less-threads
Aber da steht in den Antworten:
A common recommendation is n+1 threads, n being the number of CPU cores available. That way n threads can work the CPU while 1 thread is waiting for disk I/O.
Hat das denn so gar nichts mit meiner Frage zu tun?

 

[jabaduu]

mrBrown ich steh nicht drauf so angeraunzt zu werden. Ignorier mich doch einfach.

 

[jabaduu]

Die Anhängigkeiten die Du aufgeüfhrt hast stimmen natürlich.

 

[httpdigest]

Wie ja schon alle anderen Antworten - inklusive der akzeptierten Antwort - in dem von dir referenzierten Thread sagen, hängt es von deinem konkreten Problem ab.
Zu sagen: "A common recommendation is n+1 threads, n being the number of CPU cores available. That way n threads can work the CPU while 1 thread is waiting for disk I/O."
ist in etwa vergleichbar mit der Frage "Wieviele Leute brauche ich, um Nägel irgendwo reinzuschlagen?" und einer Antwort darauf: "Optimal sind immer N+1 Leute, wobei N = Anzahl der Nägel, die du irgendwo reinschlagen musst" ohne auch nur im allergeringsten darauf einzugehen, wie dein Problem denn geartet ist, welches du versuchst, mit Multithreading zu lösen. Z.B.: Können denn gleichzeitig alle Leute irgendwo Nägel kloppen oder muss erst ein "Bauteil" fertig sein (Parallelisierbarkeit des Problems) , um es weiter verarbeiten zu können? Oder liegen die Plätze für die Nägel so dicht beieinander (wenige Millimeter), dass sich mehrere Personen nur gegenseitig stören und auf die Finger hauen würden, wenn sie versuchen, denselben Platz einzunehmen? (Sequentialisierung durch Nutzung gemeinsamer Ressourcen)