News CPU-Boost: Windows 11 beschleunigt jetzt auch den Start von Apps

[crustenscharbap]

Ich hätte gerne noch schnelleren Boot ohne aktiviertem Schnellstart und noch schnellere Updates.
Warum muss ich mit 9800X3D und NVMe immer noch so lange auf Windows warten?

Bei mir ist gefühlt nach 60 Sekunden auf dem Desktop alles da. 🤷‍♂️

Mein Arctc Senza ist in ca 10-15 Sekunden da. Schneller als mein Mac Mini M4. Lange Bootzeiten hängen oft mit AM5 boards zusammen.

BTT: Ich habe das Gefühl bei mir isses an. Fühlt sich minimal flotte an.

 

[Piktogramm]

Selbst die Zeit die das System im UEFI verbringt wird von Microsoft protokolliert, man muss nur die Augen aufmachen und Probleme auch mal bei sich suchen.

Was heißt hier "Selbst die Zeit [..]". Das ist Teil vom ACPI 5.0 (Jan.2011) und da der Firmware Performance Data Table, dass die Firmware den Teil protokolliert und auslesbar zur Verfügung stellt. Fraglich ist halt, wieso der Wert einfach mal so in der Autostartübersicht vom Taskmanager steht. Weil Autostarts aus dem Kontext des Betriebssystem haben mit der Firmware wenig zu tun.

Jupp... Erst dann ist ein System nun mal "Ready".

Ich würde behaupten "ready" ist es, wenn der konfigurierte Zustand erreicht ist. Wo Anwendungen aus dem Autostart definitiv dazugehören. Solang dem nicht so ist, gehören da Ressourcen drauf geworfen.

Die Textanwendung wird ohne den Druckdienst völlig falsche Randeinstellungen konfigurieren und ein Spiel ohne gestartete "Spieldienste" egal welcher Art, ebenfalls in eine Fehlermeldung reinlaufen.

Also.. Windows rennt zum Graphical Target und versucht die grafische User Session auch maximal schnell anzuzeigen. Derweil hat der SCM zum Starten von Diensten ein Autodelay um ein bisschen zu warten. Tendenziell braucht es hier länger als bis zur stehenden, grafischen Session. Wenn also der Bildschirm die Usersession zeigt rödelt der SCM erwartbar noch etwas. Da im Autostart aber Programme stehen können, die Dienste brauchen, die der SCM gerade versucht zu starten, geben wir den Autostart der Usersession einen Delay mit, der auf CPU-Idle wartet. Die Autostarts aus dem Userkontext waren dabei auch aufeinander, dabei gibt es keine Abhänigkeitsauflösung eben jener Autostarts aus dem Userspace.
Alles, damit etwaige Gammelsoftware nicht in Probleme rennt. Wobei der Nutzer ab Bestehen der grafischen Session jederzeit die Chance hat selber Software zu starten, die von irgendwelchen noch nicht gestarteten Diensten bzw. Autostarts abhängt.
Ich bin wenig überzeugt... Delays einfügen in der Hoffnung, dass es sich einrüttelt läuft bei mir unter "übler Hack"[1].

Mit "deinem" Ansatz hätten wir vermutlich noch immer ein System, was nur eine Version einer Bibliothek im System zulässt und davor ausgeht die Applikationen müssten damit doch umgehen.

Was haben Shared Libraries mit Startverhalten von Betriebssystemen zu tun? An sich mag ich SLs, bin da aber nicht all zu fanatisch.



[1] Ok ich habe das so bei µControllern auch schon mit Delays implementiert. Scheiß Hack, weil Abfragen zum Zustand der zu konfigurierenden Komponente während der Konfiguration in einer Katastrophe endeten.

 

[xexex]

Was haben Shared Libraries mit Startverhalten von Betriebssystemen zu tun? An sich mag ich SLs, bin da aber nicht all zu fanatisch.

Die Lösung zu warten bis das System nach dem Boot in den Idle Zustand übergeht ist pragmatisch.

"Dein" Ansatz ist es hingegen nicht. Sollen doch alle Anwendungen lernen mit solchen Systemzuständen umzugehen, tun sie nur in der Realität nicht. In einer perfekten Welt gäbe es im System jede Bibliothek nur einmal und die könnte unabhängig von der Anwendung aktualisiert werden. Hat man versucht, hat nicht funktioniert.

Die Frage an dieser Stelle ist auch wofür? Die meisten PCs werden vielleicht einmal am Tag gestartet, da nimmt man 2-3 Sekunden lieber in Kauf, statt mögliche Fehlermeldungen oder nicht funktionierende Software. Wer es schneller will nutzt Standby, Hibernate oder den Windows Schnellstart, mit ihren ganz eigenen Problemen.

Weil Autostarts aus dem Kontext des Betriebssystem haben mit der Firmware wenig zu tun.

Wo würdest du diesen Wert sonst erwarten, wenn nicht im Tab "Autostart von Apps", wo man normalerweise als erstes reinschaut, um zu prüfen was welchen Einfluss auf die Startzeit des Rechners hat?

 

[lynx007]

Ach dehalb ist mein CPU so heiß! Toll gemacht Microsloop! Ne spass beiseite, ich muss vermutlich mal die Paste wechseln.... dann passen auch wohl wieder die Temperaturen. Aber schaut lieber nochmal bei euch allen nach! Vielelicht täusch ich mich ja, und es liegt nciht an meiner uralten "Alibaba" WLP Bei Microslop weiß man nie!!!

 

[spontan1800]

Jetzt noch die Verzögerung bei den Autostart-Programmen rausnehmen und vielleicht dauert es dann nach dem Hochfahren bei einem System mit 16C/32T nicht mehr 5 Minuten, bis alle Programme sich geöffnet ha

Oha, da läuft aber was nicht rund. Ich habe einen i5 13600K mit Win11 Home Edition und kann mich seit Jahren nicht beschweren. Fast Boot ist im Bios deaktiviert.

 

[Elektrolyt]

Solange man es deaktivieren, oder nur für bestimmte Anwendungen freigeben, kann ist es gerade noch ok.
Schlimmer wäre es wenn es wie z.B. Edge (und auch andere Browser), schon direkt nach System Start sich Ressourcen zieht, damit die Anwendung dann, wenn man sie mal braucht (also nie), schneller startet.

Was ich mich aber frage ist, wie es einige schaffen selbst mit NVME über 1 min Bootzeit hinzubekommen...

Habe mehrere Win11, Win10 u Linux Systeme Zuhause, und selbst der langsamste Win11 Rechner, mit Core I7 4770K, 16 GB RAM und SATA, benötigt max 20 Sekunden bis zum Login. Danach ist nahezu nicht im Autostart und ich ab ein responsives System, selbst auf meiner ollen Crap Gurke. Win Schnellstart selbstverständlich deaktiviert!

Ok kann natürlich auch auf unglückliche Hardware Combo (für die man nichts kann), Sicherheitssoftware oder Win 11 Bloat zusammenhängen. Oder vielleicht weil man sein OS einfach vollpumpt ohne sich Gedanken zu machen? Erlebe ich immer wieder, wenn ich mal bei Bekannten oder Kollegen zu Besuch bin...

 

[Salamimander]

Eigentlich sollte man sein OS Vollpumpen können ohne sich Gedanken zu machen, denn dass ist die Aufgabe des OS

Bei mir startet nach dem Login Mail, brave, steam, Vesktop usw. Das alles dauert keine 5 Sekunden. So soll es sein!

 

[[EH]Keeper]

mhm... bei mir schnellt der CPU-Takt nicht erst beim Programmstart in die Höhe. Es reicht schon, wenn ich einfach nur die Maus bewege. Hehe, das "boostet" ja dann noch schneller, da der CPU-Takt beim Öffnen einer App bereits durch das "mit der Maus hinfahren" auf MAX läuft und nicht erst hochtakten muss lol
"jetzt wirds endlich Rakete"
Und der CPU-Lüfter macht sich nach 5sek. "Dauer-Maus-Moving" auch schon bemerkbar... das ist jetzt mal... mhm... ich weis nicht so recht

 

[areiland]

@Salamimander
Naja, es gibt schon Leute die im Autostart nie aufräumen und alles mitstarten lassen, was sich da jemals verewigt hatte.

 

[Mondgesang]

Erinnert mich an das "Höhentraining" von Sportlern.

Mich hatte das an Dragonball erinnert, wo Son Goku immer mit Gewichtsmanschetten, Gewichtsshirt und Gewichtsstiefeln unterwegs ist. An zwei Stellen kann ich mich erinnern. Erstmals gegen Tenshin-Han im großen Turnier und dann ganz zu Beginn von Dragonball Z gegen Radditz. Kaum hatte er diese Sachen abgelegt, war er blitzschnell.

 

[Arboster]

Und wie? wo muss ich da in HWInfo schauen? Danke.

@Andy Könntest du die Frage bitte beanworten? Danke

 

[lynx007]

@Salamimander
Naja, es gibt schon Leute die im Autostart nie aufräumen und alles mitstarten lassen, was sich da jemals verewigt hatte.

Also ich fühle mich da extrem schnell "Schmutzig..." wen der Autostart vollgemüllt ist. Wen irgendwas mal "unrund" läuft, was ja viele Ursachen haben kann, ist Autostart praktisch immer der erste Schritt wo ich alles deaktivere. Oft schon nach der Installation, auch weil ich es unglaublich lästig und unverschämt finde, das Anwendungen in meinen Arbeitsspeicher setzen, Strom verbrauchen, unabh#ängig ob man sie verwende. Das hass ich wie die Pest. Würde mir wünsche das ich so ordentlich und sauber auch allen den anderen Bereichen meines Lebens vorgehen würde. GDrive, Onedrive, meine meine Rumpelkammer, Abwasch... aber mein Autostart, der ist zumindest Clean!

Daher kann ich da jetzt auch nicht wirklich mitreden. Ist Win11 lahm? Ja! Im vergleich zu Win10, auch bei leeren Autostart ist es gefühlt arschig laaahm. Aber ich habe auch nie mit der Stopuhr verglichen.... und ich habe Fastboot deaktiviert. Einfach weil ich es noch lästiger finde dann nicht mehr direkt ins Bios zu kommen. Fragt mich nicht warum Leute. Ist dumm, wen man summiert wie oft das im Jahr vorkommt. Aber es kommt so selten vor, das ich beim Restart dann vergesse Shift zu drücken, was mich wiederum dann so Tiltet, das ich Fastboot auf DISABLED hahben muss.... fragt nicht warum, versteh ich selber nicht.

ALLderdings, dann kann soo langsam kann mein Kiste auch nicht sein. Ich bin mit Win95 und HDD aufgewachsen. Und was es auch relativiert, in der Zeit wo mein Samsung nen Restart hinbekommt, schft es gefühlt WIN 5 mal rauf und runter zu fahren, selbst ohne Fastboot... daher ja WIN 11 ist halt ne lahme sau im vergleich zu Win8 und Win10, aber nichts zu Win95 wo man sich nen Kaffe wärend dem Boot vorgan brühen konnte.

 

[mae]

Das ist nichts neues und ist von Intel so vorgesehen, um ständige Threadwanderung zu minimieren und damit Prozesse mit wenig Last nicht die wichtigen Prozesse stören.

Wenn ein laengerlaufender CPU-intensiver Prozess auf einem E-Core gestartet wird und dann nach vielleicht 80ms auf einen P-Core wandert, dann hat man eine Threadwanderung, die das Starten auf dem P-Core verhindert haette.

Umgekehrt, wenn man einen Prozess hat, der immer einmal kurz laeuft, um dann wieder zu warten, waere die Migration dieses Prozesses von P nach E aus Anlass des Wartens kein Problem, auch nicht fuer die Performance, weil vermutlich schon ein Teil des Kontextes des Prozesses nicht mehr in den L1 und L2-caches liegt.

Ein System macht ständig zig Dinge im Hintergrund und jeder Taskswitch kostet viele Taktzeiten. Da ergibt es Sinn prinzipiell alles auf den vielen E-Kernen auszuführen und nur bei Bedarf oder wenn eine Applikation es anfordert, die P-Kerne zu nutzen.

In diesem Fall (und das ist der typische Zustand der meisten Systeme, die ich benutze) waren die Kerne vorher alle bei 0%-1% Auslastung. Daher ergibt es keinen Sinn, prinzipiell alles auf den vielen E-Kernen auszufuehren.

Und ein anderer typischer Fall ist auch noch, dass die meisten Prozesse nur kurz leben; shell-scripts werden aus vielen Prozessen zusammengesetzt, von denen die meisten nur kurz laufen. Und da fuehrt die Intel-Taktik dazu, die P-Cores gar nicht zu benutzen, auch wenn da nichts drauf laeuft:

# Einen Prozess starten, der 1000 Prozesse startet, einen nach dem anderen
[arrowlake:~:4557] perf stat bash -c "for i in {0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}; do /bin/true; done"

 Performance counter stats for 'bash -c for i in {0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}; do /bin/true; done':

            287.69 msec task-clock                       #    0.949 CPUs utilized             
             1_025      context-switches                 #    3.563 K/sec                     
                 7      cpu-migrations                   #   24.331 /sec                      
           105_610      page-faults                      #  367.093 K/sec                     
     1_249_529_757      cpu_atom/cycles/                 #    4.343 GHz                       
     <not counted>      cpu_core/cycles/                                                        (0.00%)
       0.303234645 seconds time elapsed

       0.240837000 seconds user
       0.078414000 seconds sys

# Und jetzt zwinge ich das System dazu, das auf einem P-Kern zu machen:
[arrowlake:~:4558] taskset -c 1 perf stat bash -c "for i in {0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}; do /bin/true; done"

 Performance counter stats for 'bash -c for i in {0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}; do /bin/true; done':

            230.48 msec task-clock                       #    0.922 CPUs utilized             
             1_002      context-switches                 #    4.347 K/sec                     
                 0      cpu-migrations                   #    0.000 /sec                      
           104_564      page-faults                      #  453.683 K/sec                     
     <not counted>      cpu_atom/cycles/                                                        (0.00%)
     1_109_789_653      cpu_core/cycles/                 #    4.815 GHz                       
       0.250021005 seconds time elapsed

       0.195993000 seconds user
       0.053664000 seconds sys

Ergebnis: mit der von Intel vorgesehenen Art laeuft dieses Beispiel um den Faktor 1.21 langsamer als wenn die Prozesse auf einem P-Core gestartet werden, der frei ist.

Wenn die P-Kerne ausgelastet sind, keine Frage, aber wenn die Maschine idle ist, ist das Starten auf den P-Kernen besser.

 

[xexex]

Wenn ein laengerlaufender CPU-intensiver Prozess auf einem E-Core gestartet wird und dann nach vielleicht 80ms auf einen P-Core wandert, dann hat man eine Threadwanderung, die das Starten auf dem P-Core verhindert haette.

Überlege einfach mal wie viele Dienste bei dir selbst auf einem frisch installierten PC laufen und wie häufig du wirklich ein Programm startest was die volle Leistung benötigt. Schnell würdest du feststellen, dass 90%+ der Tasks nicht wirklich genug sind um sie mit voller Last auszuführen, sie aber Prozesse stören würden die wirklich Last brauchen.

Lange Rede kurzer Sinn, es ist so wie es ist, Intel und Microsoft werden da bessere Benchmarks und Gründe haben. Außerdem kann eine Anwendung gezielt P-Kerne anfordern, die meisten machen es halt nicht.

To specify P-cores with OpenMP, users can use the environment variable KMP_HW_SUBSET. For a detailed description of this environment variable, refer to the Intel® C++ Compiler Classic Developer Guide and Reference. In the case of an Alder Lake processor with eight P-cores, either of the following two commands can be used for restricting threads to run only on the P-cores:

https://www.intel.com/content/www/u...ing-performance-with-heterogeneous-cores.html

 

[mae]

Überlege einfach mal wie viele Dienste bei dir selbst auf einem frisch installierten PC laufen und wie häufig du wirklich ein Programm startest was die volle Leistung benötigt. Schnell würdest du feststellen, dass 90%+ der Tasks nicht wirklich genug sind um sie mit voller Last auszuführen, sie aber Prozesse stören würden die wirklich Last brauchen.

Wuerden sie nicht, weil die 266 Prozesse, die auf dem gemessenen System drauf warten, dass sie was zu tun bekommen, alle inzwischen auf E-Kerne migriert waeren, eben weil sie warten.

Lange Rede kurzer Sinn, es ist so wie es ist, Intel und Microsoft werden da bessere Benchmarks und Gründe haben.

Wenn Microsoft irgendeinen Einfluss auf das Linux-Scheduling auf meiner Maschine haben, haben sie tatsaechlich Gruende, die aber nicht in meinem Sinn sind.

Außerdem kann eine Anwendung gezielt P-Kerne anfordern, die meisten machen es halt nicht.

Natuerlich nicht. Warum soll ein Programm wie "true" einen P-Kern anfordern? Das weiss doch ueberhaupt nicht, in welchem Kontext es aufgerufen wird, und ob die P-Kerne nicht vielleicht von anderen Prozessen belegt sind. Da waere es schon sinnvoll, wenn der Betriebssystemscheduler das richtig machen wuerde, was er aber in diesem Fall nicht tut, wie meine Messwerte beweisen.

P.S.: Ich habe mir jetzt Deinen Link angeschaut, da geht's ausschliesslich um Programme, die OpenMP benutzen, was Programme in typischen Shell-Scripts nicht machen.

 

[xexex]

Da waere es schon sinnvoll, wenn der Betriebssystemscheduler das richtig machen wuerde, was er aber in diesem Fall nicht tut, wie meine Messwerte beweisen.

Ein Scheduler kann es nicht alleine "richtig" machen, weil er nie wissen kann ob das Programm jetzt wichtig oder nur ein Nebenläufer ist. Um solche Sachen zu erkennen, hat Intel explizit der Thread Director entwickelt, den aber in der ersten Generation nicht konsequent umgesetzt. Da passiert es halt schon mal, dass die P-Kerne mit viel Müll ausgelastet waren und die E-Kerne nichts zu tun bekamen.

Das hat man nun mit den aktuellen CPUs geändert, indem man eine "E-First" Strategie fährt und sobald die Prediction sagt der Thread braucht richtig Leistung, wird er auf einen P-Kern verschoben. Im Hintergrund ist die Sache natürlich etwas komplexer und eine Applikation kann es überschreiben, aber dazu gibt es genug Quellen im Internet die es detailliert dokumentieren.

In dem verlinkten Artikel von Igor wurde es auch schon sehr detailliert erklärt, denn kann ich dir nur noch einmal ans Herz legen.

Die Softwarearchitektur von Panther Lake wurde tiefgreifend überarbeitet, um die gesteigerte Komplexität der neuen Hybridstruktur effizient zu steuern. Der überarbeitete Intel Thread Director v2 spielt dabei eine zentrale Rolle. Er überwacht in Echtzeit die Art und Intensität der laufenden Aufgaben und ordnet sie automatisch dem jeweils passenden Kerntyp zu – leistungsstarke Threads wandern auf die Cougar-Cove-P-Cores, während parallele oder hintergründige Prozesse den Darkmont-E-Cores und LP-E-Cores zugewiesen werden. Neu ist dabei der sogenannte Zoneless-Scheduling-Ansatz, bei dem Threads nicht länger festen Leistungszonen zugeordnet sind, sondern dynamisch über alle Kerne hinweg verschoben werden können.

https://www.igorslab.de/evolution-o...rchitektur-effizienz-und-softwareintegration/

 

[mae]

Ein Scheduler kann es nicht alleine "richtig" machen, weil er nie wissen kann ob das Programm jetzt wichtig oder nur ein Nebenläufer ist.

Wenn ein P-Kern eh nichts zu tun hat (oder, wie in diesem Fall, alle), spielt das keine Rolle, dann kann man ohne weiteres einen P-Kern ohne Last nehmen. Und wenn der Scheduler was anderes macht, macht er etwas falsch.

Um zu cpufreq zurueckzukommen: Am Anfang (vor 20 Jahren oder so) konnte man den noch so einstellen, dass er nice-Prozesse nicht hochgetaktet hat, und dadurch Energie sparen (habe ich beim Rippen von CDs gemacht). Diese Option ist weggefallen, seit cpufreq hauptsaechlich ueber die Firmware geregelt wird.

 

[xexex]

Wenn ein P-Kern eh nichts zu tun hat (oder, wie in diesem Fall, alle), spielt das keine Rolle, dann kann man ohne weiteres einen P-Kern ohne Last nehmen. Und wenn der Scheduler was anderes macht, macht er etwas falsch.

Noch mal für dich zu Verständnis, es wird bei Bedarf ein P-Kern genommen. Es wäre aber unvorteilhaft für alles erst einen P-Kern zu nehmen, denn die sind normalerweise begrenzt. Die Strategie ist simpel, nutze erst die vielen E-Kerne zu Vorauswahl, schaue was sie machen, verschiebe dann die Threads mit dem höchsten Leistungsbedarf auf die P-Kerne.