Was "kostet" ein Context Switch?
-
Kyon schrieb:
Ja gut, "kann" ist natürlich relativ....:-))
jo, der scheduler entscheidet ob 'geswitched' wird oder nicht. er bekommt alle 50ms die möglichkeit dazu.
guckst du auch: http://www-106.ibm.com/developerworks/linux/library/l-rt9/
da steht auch dass ein context-switch unter win doppelt so schnell beendet ist als unter linux
-
Sehr nett:
guckst du auch: http://...
Genau, was ich gesucht habe; dass Programm auf der Seite errechnet eine Context Switch Time von 1.194 auf meinem Notebook mit WinXP. Dann brauche ich mir ja keine Sorgen zu machen, wenn mein Programm mit 10 Threads 7500 ContextSwitches pro Sekunde 'verbraucht'...
Schon wieder mal ein respektvolles Danke von meiner Seite!
Gruß
-
Kyon schrieb:
1kHz
Na das will ich doch mal hoffen. Wenn ich auf meinem Notebook nur die Maus bewege werden schon 1000 Context-Switches pro Sekunde erzeugt. Bei 1kHz ist da nichts mehr mit flüssiger Bewegung...
wenn dein notebook 1MHz hat... aber dann hat man es mit dem cool'n quiet leicht übertrieben.
rapso->greets();
-
Bei 1 GHz Takt betraegt die Taktdauer genau 1 Nanosekunde.
Die maximale Umschaltzeit zwischen Tasks betraegt bei Windows 5-20 Millisekunden, bei Linux 1 Millisekunde.
D.h. es kann vorkommen, das ein Thread bei Windows fuer 5.000.000 - 20.000.000 Taktzyklen nicht drankommt, bei Linux 1.000.000.
Bei solch grobem Multitasking braucht's einen nicht wundern, wenn einem der Rechner immer so langsam vorkommt, die Programme kommen einfach nicht oft genug dran. Hat man ein Multiprozessorsystem oder eines mit Hyperthreading, verbessert sich die Lage etwas.
Das Problem wird offensichtlich, wenn man versucht, z.B. ein Musikprogramm mit kombinierter Wave-/MIDI-Ausgabe, sowie Echtzeiteffekten zu programmieren. Eine fast unloesbare Aufgabe ...
Nicht so bei aelteren Systemen wie dem Commodore Amiga, der mit nur 7,16 MHz Takt und 32-Bit Praeemptivem Multitasking in Echtzeit diese Aufgabe spielend schon 1985 erledigte, 10 Jahre bevor Windows 95 rauskam, das das immer noch nicht konnte.
:p
-
Power Off schrieb:
Die maximale Umschaltzeit zwischen Tasks betraegt bei Windows 5-20 Millisekunden, bei Linux 1 Millisekunde.
du meinst du die windoof-server versionen? da bekommen die threads extra viel kontinuierliche rechenzeit. soll für server-anwendungen wohl was bringen. wohl auch, weil es dann weniger context switches gibt.
Power Off schrieb:
D.h. es kann vorkommen, das ein Thread bei Windows fuer 5.000.000 - 20.000.000 Taktzyklen nicht drankommt, bei Linux 1.000.000.
unter windoof gilt das aber nur für threads mit geringerer priorität. hochpriorisierte threads kommen sehr oft dran, dafür haben die mit weniger prio das nachsehen.
-
20ms kann IMHO nicht stimmen, wie stellst du dir dann FarCry zocken und nebenbei Festplatte defragmentieren vor, was bei mir flüssig (70-80 fps in durchschnittlichen Spielsituationen) möglich ist?
Ich meine außerdem, irgendwas mit ~100µs gelesen zu haben, was mir wesentlich realistischer scheint. Dass das bei Server-Systemen nicht so ist, ist wohl auch klar...Bei solch grobem Multitasking braucht's einen nicht wundern, wenn einem der Rechner immer so langsam vorkommt, die Programme kommen einfach nicht oft genug dran.
Das hört sich für mich unlogisch an. Warum sollten die Programme "langsam" deswegen sein. Je feiner das Multitasking, desto mehr Zeit wird doch schließlich im Kernel verheizt.
windoof
*seufz*
-
Optimizer schrieb:
20ms kann IMHO nicht stimmen, wie stellst du dir dann FarCry zocken und nebenbei Festplatte defragmentieren vor, was bei mir flüssig (70-80 fps in durchschnittlichen Spielsituationen) möglich ist?
Ich meine außerdem, irgendwas mit ~100µs gelesen zu haben, was mir wesentlich realistischer scheint. Dass das bei Server-Systemen nicht so ist, ist wohl auch klar...Ich schrieb maximal 5-20 ms. In der Regel liegt die Zeit, nach der ein Thread wieder drankommt, bei sogar unter 100 Mikrosekunden. Leider ist dieser Wert nicht kontinuierlich. Etwa 2-3 mal pro Sekunde sind Pausen von 5-20 ms (oder darueber) nicht ungewoehnlich.
Spiele fangen so etwas durch Techniken wie Frame-Skipping ab.
Der beste Test fuer ein Multitasking ist, zwei rechenintensive Programme gleichzeitig laufen zu lassen. Lass doch mal zwei Spiele im Fenster-Modus parallel laufen.
Zu Windows-Server-Betriebssystemen kann ich nix sagen, habe die Werte unter Windows 98 und 2000 (Prof.) gemessen.
Es gibt Buecher, da steht drin, wie man Task-Scheduler schreibt, vielleicht sollte Microsoft mal eins lesen.
Fuer mich als Freund (und Entwickler) von schnellen Anwendungen ist Windows fuer Echtzeitanwendungen so gut wie voellig unbrauchbar.
Als Test fuer die reine Kontextswitching-Zeit eignen sich zwei Threads, die abwechselnd eine Mutex-Semaphore sperren (beschleunigt durch XCHG Semaphoren, d.h. zuerst wird XCHG probiert, bevor der Thread in den Wartezustand geht).
Als Zeitmesser kann man nur den RDTSC-Befehl des Prozessors verwenden, da alle Windows-Timer zu ungenau sind (haben Spruenge im 20-50 ms Bereich, auch die "precision timer"). Da die Taktzykluszeit des eigenen Prozessors bekannt ist, oder sich ggf. hochrechnen laesst, kann man mit RDTSC sehr genaue Zeitmessungen durchfuehren. Durch statistische Auswertung der Messdaten laesst sich sehr genau feststellen, wie gross die Pausen zwischen den Thread-Wechseln sind.
Optimizer schrieb:
Das hört sich für mich unlogisch an. Warum sollten die Programme "langsam" deswegen sein. Je feiner das Multitasking, desto mehr Zeit wird doch schließlich im Kernel verheizt.
Na ja, wenn ein Programm im Extremfall nur alle 20 ms laeuft, kommt es nur 50 mal pro Sekunde dran, fuer die Dauer der Zeitscheibe. Wuerde man das in eine Kurve packen, gaebe das nadelstichartige Ausschlaege, wenn der Thread laeuft.
-
net schrieb:
du meinst du die windoof-server versionen? da bekommen die threads extra viel kontinuierliche rechenzeit. soll für server-anwendungen wohl was bringen. wohl auch, weil es dann weniger context switches gibt.
Das wuerde die Antwortzeiten des Servers massiv in die Hoehe treiben, und den Verkauf teurer Server foerdern.
Rat mal, wie das frueher bei UNIX war, als die UNIX-Scheduler noch konfigurierbare Zeitscheiben im Sekunden-Bereich hatten. Du sitzt am Terminal, tippst was, dann dauerts ein paar Sekunden, und dann kannste weitertippen (beim Dumb-Terminal, das vom Server gesteuert wird). So ungefaehr laeuft das bei allen Betriebssystemen ab, die ueber Time Sharing bzw. Multitasking verfuegen.
Bei Windows ist das Multitasking extrem unregelmaessig und unzuverlaessig, so dass man ueberhaupt keine Aussage darueber treffen kann, wann ein Thread wieder drankommt. Das fuehrt dazu, dass man solche Latenzzeiten bei der Pufferung beruecksichtigen muss, wodurch die Granularitaet floeten geht (d.h. grobkoernige Reaktionszeiten der Anwendungen wg. dem Task-Scheduler).
Bei Linux ist das Multitasking fluessiger, aber leider auch nur im Millisekunden-Bereich.
Ach, sei froh, dass Du keine Hochgeschwindigkeits-Multitasking-Anwendungen programmieren musst (oder willst).
-
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