Multithreading
-
hustbaer schrieb:
Task-Switches sind im Grunde egal, da der Scheduler ja eh alle 1/n Sekunden unterbricht
Nope, ist nicht egal. Der Scheduler läuft zwar an, bloss wenn der sieht dass nix umgeschaltet werden braucht ist die ganze Sache doch schneller als wenn er switchen muss. Schon alleine deswegen weil der Inhalt des Cache grösstenteils erhalten bleibt, aber ich hoffe mal schwer dass der Fall "kein Umschalten nötig" auch so noch optimiert wurde.
Naja, die Unterbrechung springt aber in den Kernel-Mode. Sprich es gibt immer einen Task-Switch. (Ich gehe mal von den gewöhnlichen Architekturen aus. Ein Userspace Scheduler könnte das natürlich anders machen).
Und auf einem normalen Desktop Betriebssystem dürfte es auch kaum einen "kein Umschalten nötig" Fall geben.
-
rüdiger schrieb:
Und auf einem normalen Desktop Betriebssystem dürfte es auch kaum einen "kein Umschalten nötig" Fall geben.
wenn nur ein thread auf höchster prioritätsstufe in einer endlosschleife läuft, kommen die anderen nie dran. dann hängt aber auch die ganze kiste...
-
pale dog schrieb:
rüdiger schrieb:
Und auf einem normalen Desktop Betriebssystem dürfte es auch kaum einen "kein Umschalten nötig" Fall geben.
wenn nur ein thread auf höchster prioritätsstufe in einer endlosschleife läuft, kommen die anderen nie dran. dann hängt aber auch die ganze kiste...
hängt vom Scheduler ab
und klar kann er in dem Fall einfach dem Prozess die komplette Rechenzeit geben und sich ausschalten. Aber das ist ja ein sehr seltener Fall...
-
Für Threads gilt der alte Spruch: So wenige wie möglich, soviele wie nötig.
Threads "beschleunigen" nichts, sie kosten Performance. Je mehr Threads, desto mehr Overhead aka verschwendete Rechenzeit. Da Threads also Kosten haben, muß man sich klarmachen in welchem Zusammenhang sie denn Nutzen bringen.
Der Hauptsinn von Threads liegt in der Entkopplung von Aktivitäten. z.B. willst Du ja gerne noch deinen Rechenr bedienen können während der Browser gerade Daten aus dem Internet lädt. Threads geben Dir die Möglichkeit verschiedene Sachen auf deinem Rechern zu machen die sich aber nciht gegenseitig blockieren. Ein Nebeneffekt davon ist, das die Prozessorleistung optimaler ausgenutzt werden kann.
Jedoch an dem Beispiel mehrerer Berrechnungen kann man durch Multithreading theoretisch sogar einen Performancenacheil erzeugen, weil moderne CPUs durchaus in der Lage sind gewisse Aktivitäten quasi-gleichzeitig zu erledigen. Ohne den Mechanismus jetzt eingehend beschreiben zu wollen soviel: CPUs können bestimmte Operationen in Teilschreitte zerlegen und die Teilschritte mehrerer Operationen "ineinander verschachteln".
z.B. würden dann 4 Multiplikationen nicht die Dauer von 4 einzelnen Multiplikationen haben, sondern insgesamt sogar in der Zeit von 2 Multiplikationen ablaufen. (Wohl gemerkt, auf nur einer CPU). Dies klappt aber nur weil die 4 Multiplikationen auf der gleichen CPU laufen. Verteilt man die statt dessen auf mehrere CPUS geht die Möglichkeit des Schachtelns verloren... Man braucht unterm Strich auf einmal wieder länge weil ja auch ein gewisser Threading-Overhead hinzukommt.
-
rüdiger schrieb:
pale dog schrieb:
rüdiger schrieb:
Und auf einem normalen Desktop Betriebssystem dürfte es auch kaum einen "kein Umschalten nötig" Fall geben.
wenn nur ein thread auf höchster prioritätsstufe in einer endlosschleife läuft, kommen die anderen nie dran. dann hängt aber auch die ganze kiste...
hängt vom Scheduler ab
und klar kann er in dem Fall einfach dem Prozess die komplette Rechenzeit geben und sich ausschalten. Aber das ist ja ein sehr seltener Fall...naja, abschalten wird er sich nicht dabei. die CPU bekommt ja noch (alle 50mS oder so) einen interrupt, der den scheduler antickert. jener guckt erstmal nach ob die zeit des threads abgelaufen ist, ist das der fall, dann schaut er in seiner liste nach, ob ein weiterer thread auf gleicher (der höchsten) priostufe laufen will, findet keinen, und teilt dem selben thread wieder eine neue zeitscheibe zu.
...und falls das eine miese CPU ist, die nur einen instruction cache hat, wirkt sich der periodische scheduler-interrupt auf die performance recht negativ aus.
multithreading ist aus gescwindigkeitsgründen gar keine tolle sache. es ist nur gut für programmierer, die sonst (ohne multithreading) einen haufen ineinander verschachtelter statemachines und coroutines basteln müssten...
-
pale dog schrieb:
rüdiger schrieb:
pale dog schrieb:
rüdiger schrieb:
Und auf einem normalen Desktop Betriebssystem dürfte es auch kaum einen "kein Umschalten nötig" Fall geben.
wenn nur ein thread auf höchster prioritätsstufe in einer endlosschleife läuft, kommen die anderen nie dran. dann hängt aber auch die ganze kiste...
hängt vom Scheduler ab
und klar kann er in dem Fall einfach dem Prozess die komplette Rechenzeit geben und sich ausschalten. Aber das ist ja ein sehr seltener Fall...naja, abschalten wird er sich nicht dabei. die CPU bekommt ja noch (alle 50mS oder so) einen interrupt, der den scheduler antickert. jener guckt erstmal nach ob die zeit des threads abgelaufen ist, ist das der fall, dann schaut er in seiner liste nach, ob ein weiterer thread auf gleicher (der höchsten) priostufe laufen will, findet keinen, und teilt dem selben thread wieder eine neue zeitscheibe zu.
...und falls das eine miese CPU ist, die nur einen instruction cache hat, wirkt sich der periodische scheduler-interrupt auf die performance recht negativ aus.Er könnte sich aber abschalten, bis ein neuer Prozess gestartet wird. Aber wie gesagt. Das ist ja eh eine Ausnahme das man ein Prozess hat, der alle Rechenzeit bekommt und ist hier sicher auch kein geeignetes Beispiel...
Wobei der Fall ja eh nur auf einem ein Prozessor System funktioniert. Hat man zB einen anderen Kern, dann kann dort ein Prozess niedriger Priorität laufen.
-
Eeventuell ist auch eine gewisse Energieersparnis möglich. Zwei niedriger getaktete Prozessoren schaffen dann das gleiche wie ein höher getakteter Prozessor, benötigen dafür aber weniger Energie.
-
skals schrieb:
Für Threads gilt der alte Spruch: So wenige wie möglich, soviele wie nötig.
Threads "beschleunigen" nichts, sie kosten Performance. Je mehr Threads, desto mehr Overhead aka verschwendete Rechenzeit. Da Threads also Kosten haben, muß man sich klarmachen in welchem Zusammenhang sie denn Nutzen bringen.
Wie gesagt, ein großer Vorteil von Threads ist, dass die Software besser skaliert.
-
rüdiger schrieb:
Er könnte sich aber abschalten, bis ein neuer Prozess gestartet wird.
wie soll denn ein neuer prozesses/thread gestartet werden, wenn der scheduler nicht läuft?
rüdiger schrieb:
Wobei der Fall ja eh nur auf einem ein Prozessor System funktioniert. Hat man zB einen anderen Kern, dann kann dort ein Prozess niedriger Priorität laufen.
natürlich, hat man mehrere kerne, dann sollten die alle gut beschäftigt werden. ein multiprozessor-kernel würde in dem fall, wenn auf einem kern nur ein einziger high-priority thread läuft, andere threads mit niedrigeren prioritätsstufen auf anderen kernen ausführen. bei einem single-prozessor system müssten die warten.
Jester schrieb:
Eeventuell ist auch eine gewisse Energieersparnis möglich. Zwei niedriger getaktete Prozessoren schaffen dann das gleiche wie ein höher getakteter Prozessor, benötigen dafür aber weniger Energie.
ich glaub' nicht.
-
pale dog schrieb:
Jester schrieb:
Eeventuell ist auch eine gewisse Energieersparnis möglich. Zwei niedriger getaktete Prozessoren schaffen dann das gleiche wie ein höher getakteter Prozessor, benötigen dafür aber weniger Energie.
ich glaub' nicht.
Ich weiß es.
Leider kann ich den Link zu den entsprechenden Vorlesungsfolien nicht posten, weil der Assistent die bei ner Korrektur mit nem falschen Foliensatz überschrieben hat.
-
Jester schrieb:
pale dog schrieb:
Jester schrieb:
Eeventuell ist auch eine gewisse Energieersparnis möglich. Zwei niedriger getaktete Prozessoren schaffen dann das gleiche wie ein höher getakteter Prozessor, benötigen dafür aber weniger Energie.
ich glaub' nicht.
Ich weiß es.
Leider kann ich den Link zu den entsprechenden Vorlesungsfolien nicht posten, weil der Assistent die bei ner Korrektur mit nem falschen Foliensatz überschrieben hat.vielleicht liegt es daran, dass beim erhöhen der taktfrequenz der energieverbrauch quadratisch o.ä. ansteigt, während beim hinzufügen eines zweiten prozessors sich dieser nur verdoppelt?
-
Wieso sollte die Verlustleistung denn quadratisch steigen? Also bei gleichen Randbedingungen (Spannung, Architektur, Fertigung)?
-
pale dog schrieb:
rüdiger schrieb:
Er könnte sich aber abschalten, bis ein neuer Prozess gestartet wird.
wie soll denn ein neuer prozesses/thread gestartet werden, wenn der scheduler nicht läuft?
Äh? Dein Modell war doch folgendes: Es wird kein neuer Task ausgewählt, wenn wir einen Task haben der mit der höchsten Priorität läuft. Also welchen Task soll er dann auswählen? Keinen... Da wäre es wohl eine Optimierung den Scheduler auszuschalten, bis man einen neuen Task hinzufügt. Aber ich hab keine Lust über diesen Fall mehr zu reden. Der ist sinnlos und künstlich konstruiert und bringt uns nicht weiter.
-
pale dog schrieb:
Jester schrieb:
pale dog schrieb:
Jester schrieb:
Eeventuell ist auch eine gewisse Energieersparnis möglich. Zwei niedriger getaktete Prozessoren schaffen dann das gleiche wie ein höher getakteter Prozessor, benötigen dafür aber weniger Energie.
ich glaub' nicht.
Ich weiß es.
Leider kann ich den Link zu den entsprechenden Vorlesungsfolien nicht posten, weil der Assistent die bei ner Korrektur mit nem falschen Foliensatz überschrieben hat.vielleicht liegt es daran, dass beim erhöhen der taktfrequenz der energieverbrauch quadratisch o.ä. ansteigt, während beim hinzufügen eines zweiten prozessors sich dieser nur verdoppelt?
das haengt von der aufgabe ab und natuerlich den verglichenen prozessoren. normalerweise skalieren anwendungen nicht 1:1 mit mehr cores, so im schnitt, wenn sie darauf ausgelegt sind mehr cores zu nutzen, hast du mit zwei cores 80% mehr rechenleistung. also ist die energieeffiziens schonmal leicht verschlissen. zudem haengt das von der taktung ab, denn wie du gesagt hast, steigt das eine eher quadratisch und das andere linear. wenn du also zwei kerne bei 1GHz hast und mit einem 2GHz vergleichst, dann werden beide cpus in etwa gleich ziehen.
-
Am besten gleich ein eigenes OS, nur dann kann man Multifreding richtig ausnutzen...
-
Mit google findet man auch ein paar Sachen zur Energieersparnis: ftp://ftp-sop.inria.fr/pub/rapports/RR-3621.ps.gz
-
Tim schrieb:
Wieso sollte die Verlustleistung denn quadratisch steigen? Also bei gleichen Randbedingungen (Spannung, Architektur, Fertigung)?
vielleicht nicht quadratisch, aber wohl deutlich mehr als wenn man bei gleicher taktfrequenz eine zweite CPU bemühen würde. anders könnte ich mir stromersparnis durch aufteilung von threads auf mehrere CPUs nicht erklären...
rüdiger schrieb:
pale dog schrieb:
rüdiger schrieb:
Er könnte sich aber abschalten, bis ein neuer Prozess gestartet wird.
wie soll denn ein neuer prozesses/thread gestartet werden, wenn der scheduler nicht läuft?
Äh? Dein Modell war doch folgendes: Es wird kein neuer Task ausgewählt, wenn wir einen Task haben der mit der höchsten Priorität läuft. Also welchen Task soll er dann auswählen? Keinen...Da wäre es wohl eine Optimierung den Scheduler auszuschalten, bis man einen neuen Task hinzufügt.
ja, wenn kein zweiter task auf gleicher prio-stufe läuft, darf der eine endlos weiterlaufen. der scheduler darf sich aber niemals abschalten, denn selbst dieser hochpriorisierte task könnte in einen wartezustand kommen, bei dem er eine antwort von einem anderen task erwartet. in diesem fall wird rechenzeit frei, die der scheduler anderen tasks mit niedrigerer priorität zuteilen muss.
rüdiger schrieb:
Der ist sinnlos und künstlich konstruiert und bringt uns nicht weiter.
da ist nichts künstlich konstruiert. viele prioritätsbasierte scheduler arbeiten so: 'round-robin' für alle tasks einer prioritätsstufe und es werden immer zuerst höherpriorisierte tasks bei der zuteilung der rechenzeit ausgewählt.
auf einem stinknormalen PC kannst du es nachvollziehen:
1. gib dir admin rechte (braucht man um sowas zu machen)
2. gib deinem prozess die höchste prioritätsklasse
3. schreibe eine threadfunktion mit einer 'while(1);' endlosschleife
4. starte die funktion als thread mit höchster prioriotät.
--> ergebnis: die kiste hängt, noch nicht mal der mauscursor lässt sich bewegen
5. drücke den resetknopf
-
pale dog schrieb:
rüdiger schrieb:
pale dog schrieb:
rüdiger schrieb:
Er könnte sich aber abschalten, bis ein neuer Prozess gestartet wird.
wie soll denn ein neuer prozesses/thread gestartet werden, wenn der scheduler nicht läuft?
Äh? Dein Modell war doch folgendes: Es wird kein neuer Task ausgewählt, wenn wir einen Task haben der mit der höchsten Priorität läuft. Also welchen Task soll er dann auswählen? Keinen...Da wäre es wohl eine Optimierung den Scheduler auszuschalten, bis man einen neuen Task hinzufügt.
ja, wenn kein zweiter task auf gleicher prio-stufe läuft, darf der eine endlos weiterlaufen. der scheduler darf sich aber niemals abschalten, denn selbst dieser hochpriorisierte task könnte in einen wartezustand kommen, bei dem er eine antwort von einem anderen task erwartet. in diesem fall wird rechenzeit frei, die der scheduler anderen tasks mit niedrigerer priorität zuteilen muss.
der kann sich ja wieder einschalten, wenn der Prozess in einen Wartezustand kommt.
rüdiger schrieb:
Der ist sinnlos und künstlich konstruiert und bringt uns nicht weiter.
da ist nichts künstlich konstruiert. viele prioritätsbasierte scheduler arbeiten so: 'round-robin' für alle tasks einer prioritätsstufe und es werden immer zuerst höherpriorisierte tasks bei der zuteilung der rechenzeit ausgewählt.
auf einem stinknormalen PC kannst du es nachvollziehen:
1. gib dir admin rechte (braucht man um sowas zu machen)
2. gib deinem prozess die höchste prioritätsklasse
3. schreibe eine threadfunktion mit einer 'while(1);' endlosschleife
4. starte die funktion als thread mit höchster prioriotät.
--> ergebnis: die kiste hängt, noch nicht mal der mauscursor lässt sich bewegen
5. drücke den resetknopfIch hab nicht gesagt, des es nicht möglich wäre...
-
rüdiger schrieb:
der kann sich ja wieder einschalten, wenn der Prozess in einen Wartezustand kommt.
ja, das gibt's auch. z.b. einige RTOS machen sowas (TNKernel und CMX-RTX z.b.). da kann man das interruptgetriggerte scheduling abschalten und der scheduler läuft nur dann an, wenn tasksynchronisationsfunktionen aufgerufen werden etc.