Threads
-
solange die erstellung des Threads nicht mehr Rechenzeit benötigt, als dadurch eventuell gespaart wird.
-
naja wenn du trozt mehren thread nich mehr rechenzeit vom system bekommst , dann bringts nich so viel... auser du kannst wirklich threads bzw. prozesse auf hardware bzw. kerne verteilen.
Weis nich ob du durch anlegen von thread für deine anwendung mehr rechenzeit im gesamten rausholst.
-
Mehr Threads sind immer sinvoll.
Beispiel.
du willst eine Landschaft darstellen und willst eine Lightmap für diesde berechnen. Du berechnest also von jedem Punkt der Landschaft strahen zu den Lichtquellen und testest ob diese duch z.B die landschaft selbst (Berge) unterbrochen werden.
Nun willst du genau 2 Theads verwenden und teilst die landschaft in 2 gleichgroße Bereiche ein, in denen du unabhängig die Lightmap berechnest und das Ergebnis später zusammensetzt.
Nun gibt es auf einem dieser beiden Bereiche sehr viele Berge und der Strahl wird schnell und häufig unterbrochen. Somit wird auf diesem Bereich die Berechnung schnell fertig sein. Auf dem anderen Bereich wird die Berechnung sehr lange dauern weil es wenige Berge gibt.
Ergebnis: Thread 1 ist schnell fertig Thread 2 braucht deutlich länger.
Also rechnet nachdem Thread 1 fertig ist nur noch eine CPU am Problem mit Thread 2 weiter.Teilst du aber die Landschaft in deutlich mehr Bereiche so wird deutlich länger parallel gerechnet weil die Zeitunterschiede in denen die einzelnen Threads fertig werden immer kleiner werden. Also nimmt auch die Zeit ab in der nur noch 1 Thread noch nicht fertig ist und nur noch eine CPU rechnen kann.
Zahlenbeispiel (einfach ausgedacht)
Gesamtproblem 10 Sekunden
Lösung mit 2 Threads: (2 Processoren)
Thread(1) braucht 3 Sekunden + Thread(2) braucht 7 Sekunden.
Insgesamt 7 Sekunden
Es wird für 4 Sekunden nur eine CPU beschäftigtLösung mit 4 Threads (2 Processoren)
Thread(1) braucht 3.5 Sekunden + Thread (2) braucht 4.5 Sekunden +
Thread(3) braucht 5 Sekunden + Thread (4) braucht 6 Sekunden
Insgesamt 6 Sekunden
Es wird für 1 ne Sekunde nur eine CPU beschäftigt
-
MisterX schrieb:
Mehr Threads sind immer sinvoll.
Beispiel.
[...]
alternativ kannst du auch einfach zentral die gesamtaufgabe in viele einzelne teilaufgaben zerlegen und sich dann jeden thread, sobald er fertig ist, eine neue teilaufgabe vom teilaufgabenmanager holen lassen. Dann brauchst du nur so viele Threads wie CPU-Kerne.
Eine noch bessere Möglichkeit ist es, den verbleibenden Teil der Aufgabe neu unter den Threads zu verteilen, sobald einer fertig ist, sodass dann wieder alle Threads gleich viel zu tun haben. Dies darfst du allerdings nur bis zu einem bestimmten Punkt machen, ab dem es dann nichts mehr ausmacht, wenn ein Thread ein bisschen länger arbeitet als der andere, denn sonst wird das Neuaufteilen länger dauern als wenn der eine Thread einfach etwas länger arbeiten würde.
-
Das bringt nicht sehr viel, weil das Betriebssystem die Last des Programms automatisch auf die verschiedenen Kerne verteilt.
-
Apostriker schrieb:
Das bringt nicht sehr viel, weil das Betriebssystem die Last des Programms automatisch auf die verschiedenen Kerne verteilt.
Volliger blödsinn!
"Heinzelotto" hat Recht, nur ist das etwas schwieriger zu implementieren.
-
MisterX schrieb:
Apostriker schrieb:
Das bringt nicht sehr viel, weil das Betriebssystem die Last des Programms automatisch auf die verschiedenen Kerne verteilt.
Volliger blödsinn!
"Heinzelotto" hat Recht, nur ist das etwas schwieriger zu implementieren.
Informier dich mal über Hyperthreading du Dummschwätzer...
Spielt sich hier auf wie Lafontaine aber hat die Qualitäten eines Rudolf Sharping, also echt man
-
Grohool schrieb:
Wenn ich ein rechenintensives Programm schreibe, ist es dann sinnvoll das ganze auf so viele threads wie möglich zu verteilen? Ich mein im Moment haben Prozessoren 2 bis 4 Kerne, wer weiß wie viele es in Zukunft noch werde.
das optimum ist sehr von der aufgabe abhaengig. viele threads koennen zu weniger performance fuehren wenn man es falsch anstellt.
-
Informier dich mal über Hyperthreading du Dummschwätzer...
Schau Dir bitte den Artikel in Wikipedia an. Sofern dort nicht totaler Blödsinn steht, passt das nicht zu Deiner Aussage. Die pauschale Aussage "Parallelisierung durch das OS bereit gestellt" scheitert alleine schon am Unbekannten OS und eingesetzten CPU.
-
Parallelisierung gibst auf mehrere Ebene und Hyperthreading gehört zu der Ebene wo nur das Schedulen der Threads automatisch geht, wie die Parallelisierung ablaufen soll, muss der Programmierung sagen.
-
Apostriker schrieb:
Informier dich mal über Hyperthreading du Dummschwätzer...
wenn du ein bild renderst und jedem (der im Beispiel 2) Cores eine Hälfte zu rendern gibst, wobei Hälfte 1 aufgrund einer komplexeren Szenerie an dieser Stelle aber sehr viel aufwändiger als Hälfte 2 zu rendern ist, dann wird nach meinem Verständnis der Core, der Hälfte 2 bearbeitet, früher fertig sein. Dank Hyper-Threading soll es nun also möglich sein, dass der Prozessor den verbleibenden Thread, der den Rest von Hälfte 1 bearbeitet, auf zwei Cores verteilt??? Wenn das möglich wäre, bräuchten wir keine Spiele mehr zu entwickeln, die mehrere Threads benutzen.
Und selbst _falls_ das möglich wäre, sind lt. Wikipedia nur die Intel- und GCC-Compiler in der Lage, hyperthreading-code zu generieren, was das Ganze nochmal schwieriger macht.
Ferner habe ich mir diesen Algorithmus nicht ausgedacht, sondern ihn aus dem Renderer von Cinema4d, bei dem es genauso ist, wie ich beschrieben habe (das Bild wird an zwei Stellen gleichzeitig gerendert).
Spielt sich hier auf wie Lafontaine aber hat die Qualitäten eines Rudolf Sharping, also echt man
welche Politiker du toll findest und welche nicht tut hier nun wirklich nichts zur Sache
