Was "kostet" ein Context Switch?
-
Hallo, wenn die Task Wechsel im μs Bereich wären, gige zu viel Zeit mit der verwaltung drauf, da ja bei einem Wechsel alle Registerinhalte gespeichert werden müssen, damit die register für den anderen Thread zur Verfügung stehen.
-
Fuer mich als Freund (und Entwickler) von schnellen Anwendungen ist Windows fuer Echtzeitanwendungen so gut wie voellig unbrauchbar.
Redest du nun von "schnellen Anwendungen" oder von "Echtzeitanwendungen"? Ersteres ist sehrwohl auch unter Windows möglich, wenn ich es auch nicht empfehlen würde da es sicherlich speziell optimierte Unix-Versionen besser erledigen.
Wenn du aber Echtzeitanwendungen meinst fährst du mit Unix auch nicht weit, im Notfall kannst du RTLinux benützen, soll aber auch nicht der Knaller sein. Dann doch lieber QNX oder ITRON.
Aber wem erzähl ich das
MfG SideWinder
-
MisterX schrieb:
Hallo, wenn die Task Wechsel im μs Bereich wären, gige zu viel Zeit mit der verwaltung drauf, da ja bei einem Wechsel alle Registerinhalte gespeichert werden müssen, damit die register für den anderen Thread zur Verfügung stehen.
Sie sind aber im µs-Bereich und ich sehe auch nicht wirklich ein Problem damit. In beispielsweise 50µs Sekunden kann ein Prozessor schon verdammt viel machen. Natürlich ist es richtig, dass längere Zeitfenster mehr Gesamteffizienz zur Folge haben, aber für heutige Prozessoren ist das schon gut so, häufige Switches haben ja auch gewisse Vorteile.
Power Off schrieb:
Ich schrieb maximal 5-20 ms.
Naja, super. In der Regel sind es ein paar Mikrosekunden, aber du regst dich dann über 20ms auf, das passt irgendwie nicht.
Bei Windows ist das Multitasking extrem unregelmaessig und unzuverlaessig, so dass man ueberhaupt keine Aussage darueber treffen kann, wann ein Thread wieder drankommt.
Ich habe bisher keinen großartigen Grund zur Annahme, dass das unter Linux besser ist. Ich verstehe auch dein Problem nicht. Es sind beides keine Echtzeit-Systeme und ich kann damit leben.
Bei Linux ist das Multitasking fluessiger, aber leider auch nur im Millisekunden-Bereich.
Womit nichts gewonnen wäre... ms sind doch eh schon viel zu lahm.
Und wie SideWinder schon sagt, ist der Begriff "schnelle Anwendung" nicht gleichbedeutend mit "schnell reagierende Anwendung". Für so etwas ist sowohl Windows als auch Linux nicht direkt ausgelegt und was über normale Desktop-Anforderungen hinaus geht, braucht eine andere Lösung. Es ist ja nicht so, dass Echtzeit-Betriebssysteme nur Vorteile haben. Es suckt halt alles irgendwie, aber that's life.
-
MisterX schrieb:
Hallo, wenn die Task Wechsel im μs Bereich wären, gige zu viel Zeit mit der verwaltung drauf, da ja bei einem Wechsel alle Registerinhalte gespeichert werden müssen, damit die register für den anderen Thread zur Verfügung stehen.
Bei einer Taktzykluszeit von 1 Nanosekunde, waeren das fuer z.B. 100 Mikrosekunden immer noch 100.000 Taktzyklen. Hast Du schonmal Assembler programmiert?
Ganz zu schweigen davon, dass der Prozessor (z.B. Pentium 4) bis zu 20 Berechnungen pro Taktzyklus durchfuehren kann. Selbst mit langsamen Speichern sollten da innerhalb von 100 Mikrosekunden noch bequem ueber 1000 Kontextwechsel moeglich sein. D.h. Eigentlich muessten Betriebssysteme wie Windows pro Sekunde ca. 10 Millionen Kontextwechsel ohne Probleme ausfuehren koennen (auf heutiger Hardware).
Oder ein Prozess sollte bestimmen koennen, wie oft er drankommt (aehnlich wie bei Mach Kerneln). So kann man damit nicht viel anfangen.
Aber das ist alles bloss Hypothese. Otto Normalanwender merkt ja nix davon.
-
Power Off schrieb:
Ach, sei froh, dass Du keine Hochgeschwindigkeits-Multitasking-Anwendungen programmieren musst
sowas macht man auch nicht im user mode. die hochgeschwindigkeits-routinen sollte man in den kernel verfrachten, oberhalb des sogenannten 'DISPATCH_LEVEL'. da funkt einem der scheduler nicht dazwischen
-
SideWinder schrieb:
Wenn du aber Echtzeitanwendungen meinst fährst du mit Unix auch nicht weit, im Notfall kannst du RTLinux benützen, soll aber auch nicht der Knaller sein. Dann doch lieber QNX oder ITRON.
Aber wem erzähl ich das
Hmmm ... ja.
RTLinux hab ich noch nicht ausprobiert, aber von QNX weiss ich, dass die Reaktionszeit auch nicht viel besser ist als bei Linux.
Der Begriff "Realtime" ist ja auch relativ -- fuer eine Messdatenerfassung reicht oft auch 1 Sample pro Sekunde oder 1 Sample pro Minute.
Das ist ja schoen und gut, aber fuer uns ehemaligen Amiga-Freaks gibt's einfach keinen Ersatz auf dem Markt. Es ist zum kotzen!! Es gibt zwar den AmigaONE-Computer mit 800 MHz PPC CPU, aber der kostet entsprechend (und testen konnte ich den noch nicht). Das Betriebssystem AmigaOS 4 hat aber eine garantierte Message-Roundtrip-Zeit von unter 4 Mikrosekunden (also Nachricht von einem Thread zum andern und wieder zurueck).
-
net schrieb:
Power Off schrieb:
Ach, sei froh, dass Du keine Hochgeschwindigkeits-Multitasking-Anwendungen programmieren musst
sowas macht man auch nicht im user mode. die hochgeschwindigkeits-routinen sollte man in den kernel verfrachten, oberhalb des sogenannten 'DISPATCH_LEVEL'. da funkt einem der scheduler nicht dazwischen
Danke!!! Da hat sich ja mein Rumgejammer doch noch gelohnt!
-
MisterX schrieb:
Hallo, wenn die Task Wechsel im μs Bereich wären, gige zu viel Zeit mit der verwaltung drauf, da ja bei einem Wechsel alle Registerinhalte gespeichert werden müssen
wenn das das problem wäre, dann dürfte man keine unterprogramme aufrufen ;). das was am meißten kostet ist das umschalten zwischen den sicherheitsringen.
rapso->greets();
-
Sie sind aber im µs-Bereich
Nein. 10 ms.
-
Power Off schrieb:
Ganz zu schweigen davon, dass der Prozessor (z.B. Pentium 4) bis zu 20 Berechnungen pro Taktzyklus durchfuehren kann.
Quelle? Bitte zähl nicht die intern durchgeführten Adreßberechnungen mit... nur das, was er an echten Befehl schafft.
Power Off schrieb:
Selbst mit langsamen Speichern sollten da innerhalb von 100 Mikrosekunden noch bequem ueber 1000 Kontextwechsel moeglich sein. D.h. Eigentlich muessten Betriebssysteme wie Windows pro Sekunde ca. 10 Millionen Kontextwechsel ohne Probleme ausfuehren koennen (auf heutiger Hardware).
Da wär ich mir auch nicht sicher. Insbesondere falls Du zwischendrin mal was arbeiten willst solltest Du auf den Kontextwechsel noch ein paar Kosten für Cache- und TLB-Misses einrechnen.
Power Off schrieb:
Oder ein Prozess sollte bestimmen koennen, wie oft er drankommt (aehnlich wie bei Mach Kerneln). So kann man damit nicht viel anfangen.
Das Konzept jeder sagt wie oft er drankommen möchte ist auch nicht so der Bringer. Schließlich ist jeder wichtig und braucht viel Rechenzeit. Sowas ist für ein Desktop-Betriebssystem schlicht nicht geeignet.
MfG Jester