Task-Manager zeigt für Prozess mit einem Thread 25% Auslastung aller Kerne bei 4 Kernen
-
Mach doch mal die Probe und setze mit dem Taskmanager oder dem Process Explorer für deinen Prozeß eine CPU-Affinität für einen der Kerne. Wenn ich das mache, sehe ich tatsächlich mehr Auslastung auf dem jeweiligen Kern; wenn nicht, wird die Arbeitslast gleichverteilt. Warum Windows das tut, würde mich auch interessieren.
Auf dem Weg könntest du ja auch mal einen einfachen Benchmark versuchen: gibt es einen Unterschied, wenn das Programm mit und ohne CPU-Affinität rechnet? Besonders dann, wenn das Programm die größeren Caches gut ausreizt?
;qwer schrieb:
Vielleicht noch als Nachtrag, ein Kern arbeitet entweder gerade oder nicht, zu 25% oder 75% aktiv gibt es nicht.
Der Taskmanager zeigt aber nur auf (kurzen) Zeitskalen gemittelte Werte an, und da gibt es natürlich auch "zu 25% aktiv".
Eisflamme schrieb:
physikalische Kerne
Physisch, nicht physikalisch.
-
@Eisflamme
Ne single-threaded Workload läuft auch auf Windows zu einem bestimmten Zeitpunkt immer nur auf einem Kern. Warum Windows den Thread beim Scheduling die Kerne durchwechseln lässt kann ich dir nicht beantworten.
Ich vermute aber fast dass es Absicht ist. Einfach weil es vermutlich nicht gut ist wenn ein Kern die ganze Hitze abbekommt.Was den Overhead durch Kern-Wechsel und damit verbundenem Cache-Umschaufeln angeht - ich schätze mal das werden die Damen & Herren Windows schon getestet haben, und ne Scheduling-Policy implementiert die insgesamt halbwegs sinnvoll ist.
Andrerseits kann könnte ich mir auch vorstellen dass die Kern-Wechsel ein Scheduling-Artefakt sind, mit dem man lebt, weil die Alternativen noch weniger vorteilhaft wären. Halte ich allerdings für weniger wahrscheinlich.
Frage dazu: was Windows macht wissen wir ja jetzt (bzw. wer wie ich selbst mal öfter im Task-Manager mitgeguckt hat schon länger). Aber was machen andere Systeme wie z.B. Linux oder diverse BSDs? Lassen die auch den Thread rumhüpfen oder nageln die den so gut wie möglich an einem Kern fest?
-
hustbaer schrieb:
Frage dazu: was Windows macht wissen wir ja jetzt (bzw. wer wie ich selbst mal öfter im Task-Manager mitgeguckt hat schon länger). Aber was machen andere Systeme wie z.B. Linux oder diverse BSDs? Lassen die auch den Thread rumhüpfen oder nageln die den so gut wie möglich an einem Kern fest?
Linux hüpft auch fröhlich rum. Aber weitaus langsamer (man kann das Hüpfen in der Auslastungsanzeige sehen) und nach keinem Muster, das ich bisher erkennen konnte.
-
Also wenns so langsam ist dass man zugucken kann, würde ich sagen "hüpft nicht rum"
BTW: Weiss jemand wie das mit aktuellen CPUs und Interrupts aussieht? Also... auf welcher logischen CPU kommen Sachen wie Timer-Interrupts rein? Muss man das vorher einstellen, oder sucht die CPU sich das aus? Und sucht sich die CPU ne logischen CPU aus die gerade schläft oder nimmt sie gerade lieber eine die nicht schläft, um den Aufwand zu vermeiden nen Core hochzupowern? (Falls das nen nennenswerten Aufwand darstellt - keine Ahnung ob das so ist.)
-
Ich glaube die Sampling- und Update-Frequenz von htop und Konsorten ist einfach deutlich höher als die Default-Werte des Windows-Taskmanagers.
-
das scheduling von threads ist tatsaechlich CPU abhaengig und wird fuer jede thread anzahl anders evaluiert. zwei threads auf einer hyperthreading CPU wird das OS immer so verteilen wollen, dass jeweil ein core einen thread hat bei Intel, bei AMD-FX werden moeglichst zwei threads zusammengefasst, sodass sie moeglichst auf einem modul laufen, usw.
windows evaluiert das verteilen von tasks mit der internen scheduler frequenz, normalerwise 10ms getaktet, deswegen ist das auch die frequenz vom "Sleep" (gibt aber wege dran rumzuspielen).
Linux an sich wuerde eher alle threads dort belassen bis es einen grund hat diese umzuschichten, aber auch da spielen die Intel/AMD leute mit rein.interrupts werden vom OS gesteuert afaik, aber die core numerierung die wir sehen muss sowieso nicht zwingend der 'echten' entsprechen. (aus security gruenden wird das bei manchen systemen mit absicht gewechselt).
-
hab mich gerade dran erinnert dass es mal einen hotfix gab fuer den scheduler damit er besser mit dem AMD cpus funzt:
https://support.microsoft.com/en-us/kb/2645594
benchmarks dazu:
http://www.anandtech.com/show/5448/the-bulldozer-scheduling-patch-tested/3
-
rapso schrieb:
windows evaluiert das verteilen von tasks mit der internen scheduler frequenz, normalerwise 10ms getaktet, deswegen ist das auch die frequenz vom "Sleep" (gibt aber wege dran rumzuspielen).
Sollte Default nicht 15.6ms sein?
Und ein Scheduler-Quantum ist soweit ich weiss immer 31.2ms, unabhängig vom "Tick".Wobei Windows 8+ ja angeblich "tickless" ist. Bin aber nicht sicher ob das 100% so ist, oder ob im "Tick" nur viel viel weniger gemacht wird, so dass er nicht so reinhaut wie bei älteren Versionen.
bei AMD-FX werden moeglichst zwei threads zusammengefasst
Huch? Sind die FX nicht auch merklich langsamer wenn 2 Threads im selben Modul laufen?
-
hustbaer schrieb:
rapso schrieb:
windows evaluiert das verteilen von tasks mit der internen scheduler frequenz, normalerwise 10ms getaktet, deswegen ist das auch die frequenz vom "Sleep" (gibt aber wege dran rumzuspielen).
Sollte Default nicht 15.6ms sein?
um genauer zu sein: nein, es muss mit groesserer frequenz als dem quantum laufen, damit threads mit groesserer prioritaet andere unterbrechen koennen (noch waehrend des quantums). Sleep selbst laeuft mit quamtum frequenz. aus applikationssicht ist der scheduler mit quantumgeschwindigkeit unterwegs. wenn du z.b. ein sleep(0) machst und es gibt nichts was die CPU belastet und dein thread wurde vom core genommen, kann der scheduller 3mal drankommen ohne dein thread zu beachten. erst zum quantum wird dein thread wieder drankommen.
das heisst, theoretisch kannst du trotz eine quantums von z.b. 10ms, auch auf einem single-core, weit mehr als 100threads pro sekunde bedienen. du kannst aber nicht mehr als 100threads aus deinem process bedienen, weil dein prozess in der quantum frequenz gefangen ist.
Und ein Scheduler-Quantum ist soweit ich weiss immer 31.2ms, unabhängig vom "Tick".
nein, das variiert auch.
kurz googlen sagt z.B.http://cbloomrants.blogspot.de/2010/09/09-12-10-defficiency-of-windows-multi.html schrieb:
Default quantum is an ungodly 10-15 millis. But amusingly enough, there's almost always some app on your system that has done timeBeginPeriod(1), which globally sets the system quantum down to 1 milli,
oder
In Windows Server (that uses a multi-level feedback queue algorithm, FYI), the default quantum is a fixed 120ms, close to many UNIX variants (100ms) and generally accepted as a reasonably short length of time that can fool humans into believing concurrency. Compare this to the workstation-level products (Windows Vista/XP/2000 Pro) that have a variable quantum that’s much shorter and also provide a quantum (not priority) boost to the foreground process (the process in the currently active window). In the workstation products, the quantum ranges from 20-60ms typically,
hab mir den artikel nicht ganz durchgelesen.
Wobei Windows 8+ ja angeblich "tickless" ist. Bin aber nicht sicher ob das 100% so ist, oder ob im "Tick" nur viel viel weniger gemacht wird, so dass er nicht so reinhaut wie bei älteren Versionen.
ich bin mir nichtmal sicher was damit gemeint ist. der begriff ist nicht wirklich 100% definiert, afaik.
gewisse scheduling tasks muessen ja gemacht werden z.b. um prioritaet basiert tasks umzulegen. afaik wird bei windows ein quantum auch eher nur als 'budget' angesehen, ein thread kann von anderen trotzdem unterbrochen werden. entsprechend laeuft der scheduler eigentlich mit groesserer frequenz als quanten, sonst gebe es ja keine unterbrechungen. aber z.b. der mouse cursor sollte, zumindestens bei RS232, direkt von der CPU abgetastet werden. dabei wird das normalerweise nicht im interrupt selbst gemacht, sondern ein high-priority driver-task/thread geweckt.bei AMD-FX werden moeglichst zwei threads zusammengefasst
Huch? Sind die FX nicht auch merklich langsamer wenn 2 Threads im selben Modul laufen?
die idee ist wohl, dass wenn ein modul alleine laeuft, dass es die volle turbo frequenz nutzt. bei 2 modulen sinkt diese schon rapide. ich glaube das paradebeispiel war immer der 8120 (falls ich deren lustige zahlen richtig im kopf habe) der 4GHz hat bei einem modul, ich glaube es waren 3.5Ghz bei zwei modulen, 3.2Ghz bei 3 und 3.1GHz bei 4 aktiven modulen.
natuerlich ist der decoder beim 8120 bei einem module shared. beim 8320 (oder 8350?) war der decoder nicht mehr shared (glaube ich) aber dafuer die frequenz zwischen turbo vs base nicht mehr so drastisch (4.2Ghz vs 3.8Ghz glaube ich).deswegen schedulen die OS so sehr CPU abhaengig. cpu->bios->driver->kernel und in jedem schritt ist ein information loss und am ende haengt es doch vom program und ab, ob es schneller laeuft oder nicht mit einem anderen scheduling verhalten.
das problem ist, dass es keine API gibt um vom program den load an das OS hinzuweisen. ich denke die meisten threads auf mobilen geraeten wuerden mit dem minimalfrequenzen laufen. aber woher soll der kernel das wissen? entsprechend muss der kernel worst-case annehmen und voll aufdrehen.
auf android <=5 kannst du in CPU-z sehen dass ein thread immer auf volle frequenz hochgeht (bei mir >2Ghz) und andere threads sporadisch aufwachen. ab android 6 sind alle bis auf ein core im 'sleep' und der haupt core laeuft bei mir mit 300Mhz. (wenn nur cpu-z laeuft und den screen ab und zu refreshed).
der akku haelt seit Android6 nun entsprechend laenger.
das ist auch ein grund weshalb der windows scheduler variable ist, auf battery ist die frequency normalerweise hoher, damit die CPU oefter in sleep gelegt werden kann (z.b. wenn du auf vsync wartest. <1ms cpu-sleep ist es wert).
-
@rapso
OK. Ein Scheduler Quantum ist nicht fix 31.2ms, es ist Fix das doppelte vom Default-Tick.
Und der Default-Tick auf Desktop Windowsen ist seit einiger Zeit 15.6ms.
Was dann das Quantum von 31.2ms ergibt.rapso schrieb:
Sleep selbst laeuft mit quamtum frequenz.
Nö,
Sleepläuft mit Tick-Frequenz
Lässt sich ganz einfach probieren, indem mantimeBeginPeriod(1)macht. Das verkürzt den Tick, am Quantum ändert sich aber nix.Sleepwird aber "schneller". Also kannSleepnicht am Quantum hängen.rapso schrieb:
das heisst, theoretisch kannst du trotz eine quantums von z.b. 10ms, auch auf einem single-core, weit mehr als 100threads pro sekunde bedienen. du kannst aber nicht mehr als 100threads aus deinem process bedienen, weil dein prozess in der quantum frequenz gefangen ist.
Du kannst immer > 100 Threads/Sekunde bedienen.
AFAIK wird ein Thread ja nicht ausschliesslich im Tick aufgeweckt. Der Tick ist bloss der periodische Aufruf des Schedulers, wo er Timer prüft und - falls nötig - Threads schlafen legt um andere, gleich priorisierte, aufzuwecken.Wenn ein höher priorisierter Thread "runnable" wird, dann muss ja sowieso mit irgend einem Kernel-Objekt etwas passiert sein. Ein Event wurde gesetzt, ne Mutex frei, ein IO fertig - etwas in der Art.
Und wenn das passiert, dann kann Windows ja direkt gucken ob Threads die dadurch "runnable" werden sofort gescheduled werden sollten -- ohne auf den nächsten Tick zu warten.
Meiner Meinung nach läuft das auch so, weil es sich mit meinen Beobachtungen deckt.Du kannst wunderbar tausende Mal pro Sekunde zwischen zwei Threads "ping pong" spielen. Also einer weckt den anderen auf, legt sich dann schlafen, der aufgeweckte weckt wieder den einen auf, legt sich dann wiederrum schlafen usf.
Wenn Windows da jedes mal auf nen Tick warten würde, dann würde man damit nicht sehr schnell wechseln können.Genau so bei IOs -- das System würde ja komplett kastriert wenn ein Thread dessen IO fertig geworden ist nicht *sofort* wieder dran kommt.
rapso schrieb:
Wobei Windows 8+ ja angeblich "tickless" ist. Bin aber nicht sicher ob das 100% so ist, oder ob im "Tick" nur viel viel weniger gemacht wird, so dass er nicht so reinhaut wie bei älteren Versionen.
ich bin mir nichtmal sicher was damit gemeint ist. der begriff ist nicht wirklich 100% definiert, afaik.
Also für mich ist es klar -- was natürlich nicht heisst dass mein Verständnis des Begriffs richtig ist.
"Tickless" heisst für mich, dass es eben keinen "Tick" gibt
Also keinen Timer-Interrupt mit fixer Frequenz in dem das OS bloss guckt wie spät es schon ist, und ob's schon wieder Zeit ist irgendwas zu machen.Für mich schliesst das auch Interrupts mit ein die verwendet werden um "runnable" Threads gleicher Priorität durchzuwechseln.
WENN es Threads durchzuwechseln gibt, dann muss so ein Interrupt natürlich laufen.
Wenn es aber momentan keine Threads gibt die auf CPU-Zeit warten, ODER diese Threads alle kleinere Priorität haben als die die gerade aktiv laufen, dann gibt es eigentlich keinen Grund alle X Millisekunden zu gucken ob sich daran was geändert hat.
Denn alles was daran was ändern könnte bekommt der Kernel ja mit, und kann dann im Falle des Falles den Interrupt neu programmieren.Wobei ich mir aber eben nicht ganz sicher bin ob Windows 8+ das so macht. Ich hab' auch irgendwo gelesen dass Windows 8 doch noch nen fixen Tick hat, aber eben NUR mehr für den Scheduler, und nicht mehr für Timer. Weiss aber nicht wie vertrauenswürdie die Quelle war.
aber z.b. der mouse cursor sollte, zumindestens bei RS232, direkt von der CPU abgetastet werden. dabei wird das normalerweise nicht im interrupt selbst gemacht, sondern ein high-priority driver-task/thread geweckt.
Ja, klar.
Die serielle Schnittstelle hat ihren eigenen Interrupt. Darin macht der Treiber so wenig wie möglich, und fordert dann einen DPC an (Deferred Procedure Call). Und ein DPC hat "Vorrang" vor allen Usermode Thread-Prioritäten. Darin macht der Treiber den Rest. Alles weitere ist dann wieder Thread Ping-Pong. Und wenn alle beteiligten Thread ne ausreichend hohe (dynamische, also ggf. geboostete) Priorität haben, dann kommen sich auch sofort dran.ps:
Es wäre mir auch neu dass Windows Prozesse scheduled. AFAIK ist es Windows total egal zu welchem Prozess ein Thread gehört. Also abgesehen davon dass die Basis-Priorität des Threads von der Priority-Class des Prozesses abhängt. Kann batürlich sein dass ich mich täusche oder dass sich das in den letzten Jahren geändert hat.
-
Ich hab' dazu eine Offspin- Frage: Bis vor ein paar Jahren hat man ja gerne den PC direkt als CNC- Steuerung hergenommen (bis die LPTs völlig verschwunden sind), seitdem bastelt sich jeder seine USB- Schachtel.
Aber angeblich haben die Dinger bis 10 kHz clk/dir- Signale mit echten Anfahr- Rampen geliefert. Wenn ich des hier so mit den ms lese, paßt das nicht so recht zusammen, denn bis so etwa 4 kHz sollen die Teile wirklich funktioniert haben.
Ein Beispiel dafür ist das Zeug vom Lewetz. Ja, unter DOS ist mir schon klar, wie das geht, aber er hat die 10 kHz- Behauptung gleichzeitig mit der DOS- Version rausgenommen.
Richtig nachprüfen kann ich das nicht mehr (hardware futsch), aber kann man Win/Lin wirklich so austricksen, daß zwar sehr kurze, aber Timing- mäßig empfindliche Progrämmchen bedient werden?
Geht ja nicht einmal um konstante Zeitabstände, sondern um wechselnde. Wenn man einen Stepper hochzieht, fängt der bei etwa 100 Hz an und zieht auf so 4 kHz hoch, also von 10 ms bis auf ne Viertel ms.
Von 10 kHz gar nicht erst zu reden, geht also eigentlich nur, wenn man das Muster der Steuerungssignale vorausberechnet und per DMA durchschieben läßt. Oder irre ich mich da?
