Werden Threads automatisch auf die CPU's aufgeteilt?

Hallo ich habe in meinem System einen Quadcore Prozessor.
Wenn ich jetzt ein Programm mit 4 Threads programmiere, wer dann diese 4 Threads automatisch, parallel und gleichzeitig auf meine 4 Kerne aufgeteilt oder muss ich dazu noch was machen?

Sieh werden mehr oder weniger inteligenzt vom BS aufgeteilt.

Gruß pdelvo

Aber dann frage ich mich warum sich alle beschweren dass es keine Software für Quadcores gibt, weil wenn ich mir mal im Tasktmanager die Anzahl der Threads anschaue habe ich unter 88 Prozessen nur 20 die unter 4 Threads haben.

Weil das nicht alles Threads sind, die auch wirklich last erzeugen.

Achso also du meinst das BS lässt Threads nur parallel laufen wenn die auch wirklich Leistung brauchen?
Und ansonsten nur wenn die CPU gerade mal etwas Zeit hat?

Nein, eine Applikation ist einfach nicht für Mehrkern Prozessoren optimiert, wenn nur einer von wievielen Threads auch immer last erzeugt. Weil dann trotzdem nur 1 Kern wirklich arbeitet. Der Sinn einer Multicore Applikation ist es die Arbeit auf die verschiedenen Kerne aufzuteilen. Zum Beispiel beim rendern. Da übernimmt jeder Kern einen Teil der Arbeit und somit wird es schneller. Das ist aber bei den meisten Apps heute noch nicht der Fall. Zur Zeit ist es bei einigen Spielen (Crysis, World of Warcraft...) und bei vielen Render-Programmen schon drin aber es ist noch lange nicht die Regel.

Hi,

auch vor MultiCore-Zeiten hat Multithreading schon Sinn gemacht. Damit eine Aufgabe nicht die Interaktion mit dem User stört. (Sonst könntest du während des Druckens dein Textvearbeitungsprogramm deiner Wahl nicht mehr bedienen, etc.)

Und solche Aufgaben sind meistens auf mehrere Threads aufgeteilt.
Stell dir vor du schreibst ein kleines Render-Programm. Dann ist das hier schon sinnvoll:*Die GUI bekommt einen Thread (damit sie auch reagiert wenn das Programm grad "rechnet") *Die Netzwerkkomponente bekommt einen, damit sie immer im Hintergrund nach Updates prüfen kann *Die Überwachungskomponente bekommt einen, die registriert wenn du heimlich die Konfigurationsdaten verändern willst *Für Druckaufträge hast du nen eigenen Thread, damit man nebenbei schon ein neues Bild rendern kann *Und natürlich bekommt die Rendering-Berechnungsroutine nen Thread

Schon 5 Threads, die aber - bis auf den letzten - heutige CPUs nicht im geringsten fordern. Und trotzdem ist es multithreaded !
Aber wenn nun der Berechnungsthread mal wieder ordentlich was zu tun hat, kann er trotzdem nur auf einem Kern laufen, weil er selbst nur ein Thread ist. (Und die andern liegen quasi brach)

Es sollten also nicht nur die unterschiedlichen Aufgaben eines Programms auf Threads aufgeteilt werden (um die Reaktionszeit zu verkürzen), sondern: (jetzt kommts) die rechenintensiven Aufgaben müssen intern aufgesplittet werden, damit sie auch die vielen Kerne auszunutzen. Und da liegt die Schwierigkeit.

Während man bei den ganzen andern Aufgaben sich leicht vorstellt, dass/wie sie parallel agieren (da sie ja im Grunde unabhängig sind) ist das parallelisieren von Algorithmen weitaus schwerer. Gerade weil man sich die meisten Algorithmen eben sequentiell vorstellt. Erschwerend kommen dann noch Aspkete der Synchronisation und der gleichmäßige Lastverteilung hinzu. Zudem steigert ein erhöhter Parallelisierungsgrad auch die Komplexität und damit die Verständlichkeit des Codes.

Und für die Aufteilung von Threads auf CPUs ist das Betriebssystem zuständig (Scheduling). Wobei man beispielsweise unter Windows mit Prioritäts-Werten eine Wichtigkeit / Rechenhäufigkeit eines Threads beeinflussen kann.

beste Grüße
zommi

Aber dass ist doch meine Frage ob ich als Programmierer festlegen kann dass er meine Threads wirklich schön gleichmäßig verteilt und parallel auf meine Kerne aufteilt.

Das Aufteilen auf die Kerne macht er automatisch, nur du musst es so programmieren, dass es eben auch für mehrere Kerne Sinn macht. Also es auch wirklich mehrere Threads gibt, die last erzeugen. Sonst werden deine Kerne nicht ausgelastet.

Aber dass ist doch meine Frage ob ich als Programmierer festlegen kann dass er meine Threads wirklich schön gleichmäßig verteilt und parallel auf meine Kerne aufteilt.

Nein, CLR und Betriebssystem machen das im Hintergrund, unabhängig von dem Programm selbst, das ist gewollt und auch absolut richtig so. Hättest du Einfluss auf die Verteilung der Threads, würde deine Anwendung auch nur auf einer CPU-Architektur richtig laufen. Bei anderen schlecht oder auch garnicht. CLR und Betriebssystem haben verschiedene Abstraktionsschichten, die dir das Entwickeln von Programmen vereinfachen.

Wenn du eine richtige Auslastung und Verteilung von Threads auf Mehrkern CPUs erreichen willst, gibst du deinen VerwaltungsThreads (ABM) höhere Priorität als deinen WorkerThreads. Bei einer 4 Kern CPU verwendest du beispielsweise auch nicht 4 Threads sondern beispielsweise 40. Hier kannst du dir relativ sicher sein, das die einzelnen Cores von Betriebssystem richtig ausgelastet sind. Weiterhin ist das ganze nur möglich und auch performant, wenn die zu verrichtende Arbeit in kleine atomare Stückchen aufgeteilt wird und auch werden kann. Die einzelnen Stückchen können dann von verschiedenen Threads verarbeitet werden und zum Schluss wieder zu einem ganzen Zusammengesetzt werden.

Zu beachten ist allerdings, das je kleiner die Stückchen sind und je mehr Threads du hast, dass dein Synchronisationsaufwand enorm ansteigt. Wenn also jeder 2. Arbeitsthread auf einen anderen Thread warten muss, hast du was falsch gemacht.

Hervorragend lassen sich beispielsweise Video und Bildverarbeitung paralellisieren, da ein großes Bild oder ein großes Video sehr gut in kleine Teile logisch unterteilt werden kann. Problematisch wird es allerdings auch hier, wenn du beispielsweise ein Bild und 8 Arbeitsthreads hast, wo ein Weichzeichner drauf ausgeführt soll.

Hallo,

die Gründe warum man das bei Allgemeinen Applikationen so macht ist ja hier ausreichend erläutert wurden. Jetzt aber mal zu deinem konkreten Beispiel warum viele Spiele nicht Multi Threaded ausgelegt sind oder es erst jetzt Trend wird. Das größte Problem ist hier das die größte rechnerei prinzipiel die Grafikkarte macht. Deswegen läuft die hauptarbeit auf der Grafikkarte, wo es nicht üblich ist mehrer Grafikkarten in seinem System zu haben. Und deswegen auch die Grafikkartenhersteller bei Corssfire/SLI das zusammenlegen übernehmen. Sprich ein Spiel ist für eine Grafikakrte optimiert, aber durch den Crossfire/SLI Treiber wird die Last auf die mehreren Grafikkarten verteilt. Daher sind hier schonmal keine Threads. Aber Spiele brauchen doch CPU? Ja weil die Grafikkarte nicht immer alles übernehmen kann. Am meisten Rechnet die CPU bei Spielen an der Physik. Es gibt jetzt mittlerweile PhysX von Nvidia wo das auch Grafikakrten technisch geregelt wird aber auch dort kommt die CPU auch noch im Einsatz. Aber viele Spiele rechnen die Physik großteils halt auf der CPU. Da die Physik in den Spielen immer besser wird brauch man auch mehr leistung wo man sich überlegen könnte es vielleicht Threaded zu machen. Bei Netzwerkspielen wird durch die Onboard Netzwerkkarten meist die CPU belastet die packete schön zu machen. Kann man auch in einen Thrad machen wenn man mag. Naja das sind halt so die Gründe warum es nicht so häufig ist das Spiele multi threaded sind, weil vorallem es häufig nicht soviel bringt. (Ausnahmen bestätigen die Regel)

Gruß Kaji

Die KI ließe sich hervorragend auf mehre CPUs verteilen. Ein Ballerspiel, wo Gegner direkt ins Messer laufen find ich langweilig. Besser ist es, Gegner zu haben, die sich verstecken, in Deckung geben oder anderen einer Gruppe Feuerschutz geben.