Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
News Schnellere App-Starts in Windows 11: CPU-Boost laut Microsoft-Entwickler kein „Cheating“
Piktogramm
Fleet Admiral
- Registriert
- Okt. 2008
- Beiträge
- 10.281
Scheduler verteilen Prozesse/Threads auf Prozessoren bzw. bestimmen wann die Prozesse wie lange auf den Prozessoren laufen. Governor regeln die CPU-Energiezustände bzw. Frequenz.Alphanerd schrieb:Jetzt: man klickt und scheduler geht automatisch auf den höchsten takt, weil Programm xyz.
Ergänzung ()
Ergänzung ()
Den Prozessoranbietern wurde ihre aggressive, spekulative Ausführung mit Spectre, Meltdown & Co reichlich um die Ohren gehauen..aspro schrieb:Das kann man ja genauso den CPU-Herstellern vorwerfen, die Operationen schon im Voraus berechnen (Branch Prediction)
Zuletzt bearbeitet:
aspro
Captain
- Registriert
- Mai 2004
- Beiträge
- 3.594
@Piktogramm Mag sein, aber an der Tatsache hat sich ja nichts geändert und realistisch betrachtet ist es ja nicht wegzudenken, es sorgt schließlich für massive Performancesteigerungen.
Medcha schrieb:Ich wusste damals und bis heute nicht, warum in aller Welt hätte ich den Turboknopf nicht dücken sollen?
Weil der Turbo Knopf genau das Gegenteil gemacht hat von dem, was der Name sagt.
Alexander2
Fleet Admiral
- Registriert
- Aug. 2014
- Beiträge
- 16.578
Nein, ICH BIN die Matrix!Trinoo schrieb:Gerade die Linux Fraktion tut ja oft so, als ob sie den Matrixcode lesen kann 😂
Ergänzung ()
Das gleiche mit Linuxigi666 schrieb:schaffe ich es auf 42% CPU Last.
Plasmashell+kwin_wayland zusammen kommen auf 1% dabei
(die Kernzahl ist ansatzweise ähnlich zu deinen - wegen dem Prozenten - 9950x3d)
Da fragt man sich echt, was da alles so berechnet wird jedes mal :-)
Zuletzt bearbeitet:
Verstehe den Sinn nicht sollte die CPU nicht generell hochtakten wenn eine Anwendung dies benötigt und anfordert oder hat MS da einfach nur scheiße programmiert?






Und man kann die Taskleiste immer noch nicht verschieben eine Funktion seit Windows 95 raus zu nehmen ist der wirkliche Skandal neben der digitalen Analsonde äh Kontozwang.
Ergänzung ()
Wurde von Intel erst letzte Woche vorgestellt.CDLABSRadonP... schrieb:Man kommt sich vor, als wäre der TurboBoost erst ein paar Monate alt, oder?
Ergänzung ()
Dieses Webview2 Scheiß sollten sie wieder raus nehmen, bringt nichts nur Ärger.Rickmer schrieb:Dass das Startmenü und andere Fenster die Webview oder React nutzen auf windows-native umprogrammieren etwas länger dauert sollte schon klar sein... wenn die das jetzt schnell vibe coden und buggy auf den Markt bringen ist der nächste Shitstorm vorprogrammiert
Und man kann die Taskleiste immer noch nicht verschieben eine Funktion seit Windows 95 raus zu nehmen ist der wirkliche Skandal neben der digitalen Analsonde äh Kontozwang.
Ergänzung ()
Der übertaktet die CPU doch nicht über die offizielle Norm?Stahlseele schrieb:Natürlich ist das Cheating.
Vor allem verbraucht es mehr Strom. UND verkürzt die Lebensdauer des Prozessors.
Zuletzt bearbeitet:
IDontWantAName
Captain
- Registriert
- Dez. 2011
- Beiträge
- 3.755
igi666 schrieb:Hat das mal einer von euch getestet, wie katastrophal das Win11 Startmenue ist?
Mein Arbeitslaptop hat nen Core Ultra 7 165H....wenn ich jetzt so schnell es geht die Windows Taste druecke (also Menue auf und zu, auf und zu....) schaffe ich es auf 42% CPU Last.
Zeichne mal einen Trace davon auf, mich würde mal interessieren was das Startmenü da macht. Nutze schon ewig StartAllBack/StartIsBack also keine Ahnung was MS da gefummelt hat.
stefan92x schrieb:Das ist ganz banal alles, die Regelung wird jetzt etwas zackiger.
Das war früher so, ab Kaby Lake hat die Intel CPU das selber erkannt und konnte schneller den Takt senken/erhöhen (Intel Speed Shift Technology (HWP - Hardware P-states)). Deshalb frage ich mich was MS da jetzt genau ändern will. Denn wenn ersz das OS die Änderungen anregt ist es eigentlich langsamer.
Khorneflakes
Lt. Commander
- Registriert
- Juli 2024
- Beiträge
- 1.403
Das Mindset mancher "Entwickler" ist einfach so komplett daneben. Solche Leute hätte man früher einfach entlassen. Oder garnicht erst eingestellt. Die sind offensichtlich für den Job nicht qualifiziert.
Breaking News: Der ganze Moloch wäre noch performanter, wenn man die CPU einfach dauerhaft auf Anschlag laufen lassen und alle Energiesparmaßnahmen der Hardware abschalten würde.
Das ist das Gegenteil von Optimierung. Anstatt mit vorhandenen Ressourcen ein besseres Ergebnis zu produzieren, will man hier Hardware auf das Performanceproblem werfen um mit mehr Ressourcen das Ergebnis zu erreichen, welches man vorher schon hätte erreicht haben sollen.
Unglaublich. Dass es Leute gibt, die sich darüber beschweren, ist nicht verwunderlich. Verwunderlich ist, dass es noch Leute gibt, die diese Maßnahme verteidigen.
Breaking News: Der ganze Moloch wäre noch performanter, wenn man die CPU einfach dauerhaft auf Anschlag laufen lassen und alle Energiesparmaßnahmen der Hardware abschalten würde.
Das ist das Gegenteil von Optimierung. Anstatt mit vorhandenen Ressourcen ein besseres Ergebnis zu produzieren, will man hier Hardware auf das Performanceproblem werfen um mit mehr Ressourcen das Ergebnis zu erreichen, welches man vorher schon hätte erreicht haben sollen.
Unglaublich. Dass es Leute gibt, die sich darüber beschweren, ist nicht verwunderlich. Verwunderlich ist, dass es noch Leute gibt, die diese Maßnahme verteidigen.
Khorneflakes schrieb:Anstatt mit vorhandenen Ressourcen ein besseres Ergebnis zu produzieren
Genau das wird doch gemacht. Die vorhandenen Hardwareressourcen werden aktiviert, wenn sie gebraucht werden.
Nachteile: keine.
Fehlkonzipierte Systeme mit schlechter Lüfterregelung oder sinnlos übertriebener Übertaktung nerven auch in anderen Situationen durch unnötigen Krach oder erhöhten Energiebedarf, da machen ein paar Sekunden Boost den Braten auch nicht mehr fett.
grabeskuehle
Lt. Junior Grade
- Registriert
- Okt. 2014
- Beiträge
- 332
Was mich jetzt nach kurzem nachdenken und lesen weiterer Kommentare wundert ist, was Microsoft da überhaupt veranstaltet hat. Zu Agressive Energiesparmaßnahmen wahrscheinlich.
Weil so wie ich die Boost Funktion von aktuellen CPU's vertsanden habe, sollte eh die CPU selbst entscheiden wann sie boostet. Eben wenn genug Headroom bei Temperatur und Stromaufnahme, sowie eine entsprechende Auslastung da ist.
Da hätte ich ja geglaubt das CPU's genau in Szenarien wie einem Appstart auch von selbst Boosten würden, durch die kurze Lastspitze.
Könnt natürlich auch sein das ich ganz falsch liege, hab mich da schon länger nicht mehr eingelesen.
Weil so wie ich die Boost Funktion von aktuellen CPU's vertsanden habe, sollte eh die CPU selbst entscheiden wann sie boostet. Eben wenn genug Headroom bei Temperatur und Stromaufnahme, sowie eine entsprechende Auslastung da ist.
Da hätte ich ja geglaubt das CPU's genau in Szenarien wie einem Appstart auch von selbst Boosten würden, durch die kurze Lastspitze.
Könnt natürlich auch sein das ich ganz falsch liege, hab mich da schon länger nicht mehr eingelesen.
iron_monkey
Vice Admiral
- Registriert
- Juli 2005
- Beiträge
- 6.674
Alexander2 schrieb:Das gleiche mit Linux
Plasmashell+kwin_wayland zusammen kommen auf 1% dabei
Mit Win10 komme ich auf 3-4% Last, wenn ich auf die Win-Taste hämmer... (8700G).
Zuletzt bearbeitet:
Bigeagle
Lt. Commander
- Registriert
- Nov. 2008
- Beiträge
- 1.676
geht da nicht alles < 1ms in buffer? so ein paar samples audiopuffer hat man doch eigentlich immer, wenn nicht mehrere ms.chillipepper schrieb:Für Audio-Processing benötigst Du einen stabilen Systemtakt, um interne Latenzen beim Processing, verursacht durch Taktwechsel, zu minimieren bzw. auszuschließen.
je nachdem was man so macht, kp wo die grenze ist wenn man ton verarbeitet und das dann ggf. mit dem live ton überlagert wird.
aber afaik ändert jede moderne cpu standardmäßig ständig ihren takt. beispiel dauerlast im powerlimit, der takt springt die ganze zeit hoch und runter um das einzuhalten. was länger dauert ist eher den schlafmodi aufzuwachen und evtl das warten auf die spannung wenn die cpu von idle auf vollast wechselt. bei einem kontinuierlichen audio processing sollte letzteres nicht vorkommen, dafür sind die wartezeiten nicht lang genug, bzw die programme sollten dann schlichtweg busy waiting machen wenn es so latenzkritisch ist.
das sollte eigentlich nicht hörbar sein nach meinem verständnis. eine gewisse mindestlatenz hat man afaik sowieso auf normalen pcs. also noch etwas mehr als bei auch echtzeit ausgelegten DSP.
chillipepper
Lieutenant
- Registriert
- Dez. 2022
- Beiträge
- 820
@Bigeagle Meine Einstellungen sind im BIOS so gewählt, dass ich über das Energieprofil steuern kann, ob und wie viele Cores geparkt werden und welchen Systemtakt ich verwenden möchte.
Wenn ich neben EIST auch TURBO aktiviere, dann hält der E5-1680v4 permanent den All-Core-Turbo-Multiplikator – auch im Idle – und läuft konstant auf 3,6 statt 3,4 GHz auf allen 8/16 Cores. Das bevorzuge ich, weil sich damit sehr geringe DPC-Latenzen erzielen lassen. P-State-Transitionen sind nicht verzögerungsfrei: Laut Internetinfos gemessen an Intel-Xeon-Prozessoren der Sandy-Bridge-EP- und Ivy-Bridge-EP-Generation liegen die Übergangslatenzen typischerweise bei 10–50 µs, im Worst-Case mit größeren Multiplikator- und Spannungssprüngen bis ~100 µs und das ist schon eine Menge.
DPC-Latenzen liegen typischerweise zwischen 1 und 1000 µs — oberhalb dieser Grenze eignet sich lt. LatencyMon Messtool ein System nicht mehr für die Echtzeitverarbeitung von Audio bzw. den Einsatz von Recording-Interfaces. Und knapp unter den 1000 µs möchte man auch ungerne liegen.
Bei meinem System habe ich bei einen unbelasteten System DPC Latenzen (gemessen Interrupt zu User Prozess) von Minimum ~10 µs bis etwa 50µs mit gelegentlichen Peaks von 80 oder leicht über 100.
Das sind hervorragende Werte.
Je geringer die DPC-Latenzen und deren Peaks sind, desto effizienter kann die CPU arbeiten und ihre Performance auch abrufen. Das ermöglicht knackserfreies Arbeiten mit einem Recording Interface auch bei höherer Last oder kleineren ASIO-Buffersizes bis runter zu 32 Samples @single speed.
Auch fürs Gaming ist es vorteilhaft, wenn alle Cores durchgängig arbeiten können, damit alle Cores gleichermaßen die Systemlast möglichst verzögerungsfrei abarbeiten können.
Allein die P-State-Übergangslatenzen von bis zu 100 µs entsprechen bereits rund 10 % der tolerierbaren DPC-Latenzen. Da diese Wechsel wiederholt auftreten, kann ein Core für jeweils ~100 µs blockiert sein – sind in diesem Moment Audioprozesse auf genau diesen Core gescheduled, ist das schlicht suboptimal und beim DAW-Tuning möglichst zu vermeiden.
Aus demselben Grund arbeite ich ungerne mit klassischem Turbo Boost: Dessen Frequenzanhebung gilt ohnehin nur für einzelne Cores unter bestimmten Bedingungen – und erfordert häufig, dass andere Cores geparkt werden.
CPU‑Core-Parking handelt sich seinerseits noch deutlich höhere Latenzen ein: Das Aufwachen eines geparkten Cores aus dem C6-State dauert laut verfügbaren Messungen typischerweise 100–500 µs und das ist einfach nicht mehr tolerabel, dass ein Core für so lange Zeit ausfällt.
So attraktiv Turbo für Single-Thread-Performance oder einzelne Applikationen sein mag - im Kontext eines agilen Systems, das auch Audiobearbeitung oder Gaming leisten soll - halte ich klassischen Turbo für suboptimal.
Ich arbeite daher lieber mit CPUs, die einen hohen Grundtakt auf allen Cores ermöglichen (dürfen also nicht zu viele cores haben). In meiner Konfiguration liefert mir der Turbo-Mechanismus genau das: den Multiplikator für einen stabilen All-Core-Boost — ohne die Nachteile dynamischer Einzelcore-Anhebungen.
Und das liefert bei meiner CPU konstant 200 MHz mehr, 3.6 statt 3.4 GHz. Immerhin.
Einzige Ausnahme: Wird Code mit AVX-Instruktionen ausgeführt, greift eine von Intel dokumentierte Frequenzlimitierung auf 3,4 GHz., bedingt durch den erhöhten Strombedarf der Vektoreinheiten.
Wenn ich neben EIST auch TURBO aktiviere, dann hält der E5-1680v4 permanent den All-Core-Turbo-Multiplikator – auch im Idle – und läuft konstant auf 3,6 statt 3,4 GHz auf allen 8/16 Cores. Das bevorzuge ich, weil sich damit sehr geringe DPC-Latenzen erzielen lassen. P-State-Transitionen sind nicht verzögerungsfrei: Laut Internetinfos gemessen an Intel-Xeon-Prozessoren der Sandy-Bridge-EP- und Ivy-Bridge-EP-Generation liegen die Übergangslatenzen typischerweise bei 10–50 µs, im Worst-Case mit größeren Multiplikator- und Spannungssprüngen bis ~100 µs und das ist schon eine Menge.
DPC-Latenzen liegen typischerweise zwischen 1 und 1000 µs — oberhalb dieser Grenze eignet sich lt. LatencyMon Messtool ein System nicht mehr für die Echtzeitverarbeitung von Audio bzw. den Einsatz von Recording-Interfaces. Und knapp unter den 1000 µs möchte man auch ungerne liegen.
Bei meinem System habe ich bei einen unbelasteten System DPC Latenzen (gemessen Interrupt zu User Prozess) von Minimum ~10 µs bis etwa 50µs mit gelegentlichen Peaks von 80 oder leicht über 100.
Das sind hervorragende Werte.
Je geringer die DPC-Latenzen und deren Peaks sind, desto effizienter kann die CPU arbeiten und ihre Performance auch abrufen. Das ermöglicht knackserfreies Arbeiten mit einem Recording Interface auch bei höherer Last oder kleineren ASIO-Buffersizes bis runter zu 32 Samples @single speed.
Auch fürs Gaming ist es vorteilhaft, wenn alle Cores durchgängig arbeiten können, damit alle Cores gleichermaßen die Systemlast möglichst verzögerungsfrei abarbeiten können.
Allein die P-State-Übergangslatenzen von bis zu 100 µs entsprechen bereits rund 10 % der tolerierbaren DPC-Latenzen. Da diese Wechsel wiederholt auftreten, kann ein Core für jeweils ~100 µs blockiert sein – sind in diesem Moment Audioprozesse auf genau diesen Core gescheduled, ist das schlicht suboptimal und beim DAW-Tuning möglichst zu vermeiden.
Aus demselben Grund arbeite ich ungerne mit klassischem Turbo Boost: Dessen Frequenzanhebung gilt ohnehin nur für einzelne Cores unter bestimmten Bedingungen – und erfordert häufig, dass andere Cores geparkt werden.
CPU‑Core-Parking handelt sich seinerseits noch deutlich höhere Latenzen ein: Das Aufwachen eines geparkten Cores aus dem C6-State dauert laut verfügbaren Messungen typischerweise 100–500 µs und das ist einfach nicht mehr tolerabel, dass ein Core für so lange Zeit ausfällt.
So attraktiv Turbo für Single-Thread-Performance oder einzelne Applikationen sein mag - im Kontext eines agilen Systems, das auch Audiobearbeitung oder Gaming leisten soll - halte ich klassischen Turbo für suboptimal.
Ich arbeite daher lieber mit CPUs, die einen hohen Grundtakt auf allen Cores ermöglichen (dürfen also nicht zu viele cores haben). In meiner Konfiguration liefert mir der Turbo-Mechanismus genau das: den Multiplikator für einen stabilen All-Core-Boost — ohne die Nachteile dynamischer Einzelcore-Anhebungen.
Und das liefert bei meiner CPU konstant 200 MHz mehr, 3.6 statt 3.4 GHz. Immerhin.
Einzige Ausnahme: Wird Code mit AVX-Instruktionen ausgeführt, greift eine von Intel dokumentierte Frequenzlimitierung auf 3,4 GHz., bedingt durch den erhöhten Strombedarf der Vektoreinheiten.
JMP $FCE2 schrieb:Das ist dann eine schlecht gemachte Lüftersteuerung - so ein Gerät würde ich sofort zurückgeben. Kein Kühlkörper heizt sich so schnell auf, dass es technisch notwendig ist, bei Sekundenbruchteilen Vollast sofort den Lüfter auf Maximum zu drehen.
Mein Lenovo E495 z.B. reagiert überhaupt nicht auf Lastspitzen, der Lüfter bleibt unauffällig. Erst wenn ich ein Spiel starte oder anderweitig Dauerlast abfordere, dreht der Lüfter allmählich hoch. Das gleiche beim HP Prodesk 600 G5 Mini-PC.
Bei üblichen Midi-Towern ist die Sache sogar noch leichter: Kühler-Overkill und Festdrehzahl. Mein Zockrechner hat einen 65/88-Watt-Ryzen mit Towerkühler und 120 mm-Lüfter. Den habe ich auf konstante 800 U/min eingestellt, und er ist praktisch unhörbar. Egal, ob idle oder beim Cinebench-Dauertest.
Leseprofi am Start, ich meinte doch explizit die "kleineren portablen" oder nimm auch z.B. Mini-PCs oder lass es kleinere Tablets und Convertables mit Lüfterchen sein. Da ist halt einfach kein großer Towerkühler drin.
Und auch abseits deines optimierten Tower-PCs mit sehr leiser Kühlung, gibt es aber nun mal zig Geräte mit Standard-Kühllösungen die dann laut sind.
Und schon klar das die Lüftersteuerungen und Profile nicht überall gleich gut funktionieren, manch ein Bios hat so etwas sogar überhaupt nicht.
Toll wenn es bei deinen Geräten nicht so ist.
Wenn Du aber so ein kleines Gerät sehr leise betreiben möchtest, ist schon der CPU Turbo Modus schlecht gemacht, weil insbesondere AMD viel zu viel Turbo-Takt hat und dieser bereits gezähmt werden muss.
Und dann funkt demnächst noch Microsoft wieder dazwischen, weil sie einfach nur nicht mehr in der Lage sind vernünftig zu programmieren und zu optimieren und dann denkt vielleicht auch Dein Gerät beim öffnen des Explorers das ein Spiel gestartet wurde und dreht dann ordentlich auf...
Bestimmt ist das auch wieder nur der Anfang von Microsfts "Optimierungen", wer weiß was dann noch kommt.
Und insgesamt verbrauchst Du damit auch wieder mehr Strom!
Klar, das ist bestimmt die beste Lösung...
1776 schrieb:???????
Was ist das Problem?
Benutz das neue PowerProfil halt einfach nicht?
Du wirst nicht dazu gezwungen es zu nutzen! 🤷♂️
Klassiker-Antwort wenn man gar nichts vernünftiges dazu beisteuern kann, zumal das bestimmt wieder als Standard reingedrückt wird in das System und man erst wieder aktiv gegensteuern muss...
Ähnliche Themen
- Antworten
- 129
- Aufrufe
- 10.130