News Speed Shift: Höhere Skylake-Effizienz mit Update für Windows 10

@Cyberae

Sehr viel Doku und Quelltext lesen.

-------------------------------------------

Das OS hat nur bedingt einen besseren Einblick zur Steuerung der P-States. Dazu müsste das OS perspektivisch das Laufzeitverhalten des Threads in der Zukunft kennen, was ein Ding der Unmöglichkeit ist. Deswegen gibt es ja auch verschiedene CPU-Sheduler, die dieses Problem durch unterschiedliche Steuerprofile der P-States angehen. Alle mit Vor- und Nachteilen und SpeedShift ist ein neues Konzept, welches einige Nachteile ausbügelt, ohne (auf den ersten Blick) bösen Overhead zu erzeugen.
 
Gute Sache. Ich habe häufig das Gefühl, dass das Betriebssystem die core sowie package states bei weitem nicht optimal regelt.
 
Jesterfox schrieb:
@Fragger911: ja, aber MS braucht eben keine Märchen zu erfinden weshalb sie das nicht für Windows 7 bringen. Der Hinweis auf den Support reicht da schon aus. Bei Win 8 ist es was anderes, da könnten sie aber mit Irrelevanz des Systems argumentieren ;-) die meisten Win 8 User dürfte wohl wenig Gründe haben nicht auf 10 zu wechseln.

Ich meine da geht es weniger um Microsoft als um Intel, denn welches OS auf Skylake läuft sollte denen egal sein - Hauptsache sie verkaufen Prozessoren und Systeme. Lassen wir Intel die SpeedShift-Funktionalität per Treiber für alle gängigen Betriebssysteme veröffentlichen, dann kann sich MS maximal noch bei der WHQL-Zertifizierung der Treiber querstellen... mMn
Deshalb ja auch der Hinweis auf Linux, für das Intel nativen Support bieten sollte anstatt die Jungs & Mädels das Funktionieren dieses Features erst herbeizaubern müssten (jetzt ungeachtet dessen ob es nun schon geht oder nicht, mir geht es um's Prinzip).
 
Es wäre schon durchaus interessant, was man mit einem agressiveren CPU-Governor unter Windows erreichen könnte. Ist komplett spekulativ, aber ich würde sagen: Vielleicht ist der unter Windows eher etwas zu vorsichtig. Denn längere Akkulaufzeiten machen sich eventuell besser als erhöhte Snapiness, die man schwerer messen kann. Und bei den üblichen Benches läuft die CPU eh volle Pulle - > voller Score.
Natürlich kann man Prinzipbedingt SpeedShift nicht einfach emulieren, aber die Zeiten die in den Artikeln genannt werden für state Umschaltung via OS erscheinen mir doch recht lange..
 
@Jesterfox:
Gut möglich, dafür fehlt mir die Sachkenntnis. Mir ging es halt auch um andere OS. Aber ist schon ok, mich wird es in der aktuellen Fassung "Skylake" nicht tangieren, geschweige denn treffen :D (siehe unten)

@R4Z3R:
Danke, genau das meinte ich.
 
Gerade für die mobile Fraktion sehr interessant! Bitte testen und auswerten @ComputerBase
 
@Onatik: Bei Anandtech gibt's schon Zahlen. Tendenziell investiert Intel den Vorteil durch SpeedShift offenbar eher in mehr Snapiness als in verlängerte Laufzeiten.

(Würde generell vermuten dass man Low-Level Infos besser in Snapiness ummünzen kann und Higher-Level Infos besser in Energieeffizienz)
 
Die Effizienz könnte man um mehrere tausend Prozent steigern wenn man vorab ein vernüftiges OS nutzen würde :rolleyes: für mich klingt das nach Marketinggewäsch, was unterm Strich bleibt wird sich zeigen.
 
+1

Es wäre nützlicher, wenn das OS und jede Anwendung möglichst viele Kerne und Hyperthreading auslasten könnten oder wenn man nur einen Kern ansprechen kann, wäre es sinnvoll, auf diesem Kern HT abzuschalten.. Bisher kann es sein, dass ein Virenscan auf einer CPU mit 2 Kernen ohne HT viel schneller fertig ist als auf 4 Kernen mit HT. Auf der einen CPU bekommt die Aufgabe dann 50% der CPU und auf der anderen CPU nur 12,5%.
 
Zuletzt bearbeitet:
Naja das Gegenteil ist ja gerade die Motivation für Intel - auf OS-Ebene kann ich halt auch nur aus der OS-Sicht optimieren. Auf Chipebene betrachtet hat man eben weitere Energie-relevante Informationen die man nun versucht zu nutzen.

Und ein paar Tausend Prozent via OS Optimierung kannst du vergessen ;) Gewisse Arbeiten müssen halt gemacht werden. Bei der ganzen Regelung geht es ja nur um kleine Zeitfenster für die man halt entscheiden muss, wie agressiv man taktet.. Bei Vollast und Idle handeln früher oder später jedes System gleich (Takt voll hoch, Takt maximal runter).
Ergänzung ()

Betriebssystem können via ACPI erkennen, welche Kerne echt sind und welche nicht. Sofern es sich nicht um eine exotische Situation handelt, hat das OS deshalb sehr wohl die Info um solche "Anfänger" -Fehler a la "rechne auf virtuellen Core obwohl echter frei" zu vermeiden. Denn: Schon mit dem simplen Ansatz "Echte Kerne zuerst belegen" sollte man recht weit kommen. Ohne HT müsste man sich für einen fünften Thread quasi auf die harte Tour einen physischen Kern teilen - mit HT profitiert man immerhin davon dass bis zu 30% des 5. Threads kostenlos sind, im Sinne von "Lücken in der Pipeline gestopft".
 
Zuletzt bearbeitet:
Cool Master schrieb:
Das ist mir bewusst. Da ist es aber Sinvoller das OS zu optimieren statt die HW. Bsp. dafür ist z.B. App Nap von Apple. Sobald ein Fenster verdeckt ist geht die App in eine Art Standby und verbrauch praktisch nichts mehr.

Ich weiß ja, Apple ist ganz toll und so: aber sollte man das nicht lieber dem Programm überlassen? Welche ordentlich programmierte Applikation macht schon andauernd irgendwas, wenn sie gar nicht aktiv ist bzw. es keine Interaktionen gibt?!

Nebenbei möchte ich mich als Programmierer nicht mit Fehlfunktionen rumschlagen müssen, weil das Betriebssystem der Meinung ist mein Programm (nein "meine App") deaktivieren zu müssen.

Das ist nur in Browsers sinnvoll. Und die machen das mMn sowieso.
 
Nachteil dieser Funktion:
Wieder mehr hochfrequente Peaks auf den Kondensatoren der Netzteile. Ist im Prinzip nichts anderes als bei den Grafikkarten.

Belastbare Kondensatoren werden bei einer langen Nutzungsdauer eines Netzteils wieder ein wenig wichtiger. Wer eh nur 2 Jahre plant braucht sich da kaum Sorgen machen. Die zeit schaffen selbst unschöne Kondensatoren noch.
 
Es ist quasi ein Workaround von Intel um die Probleme des OS zu umgehen. Bisher ist es so, dass praktisch alle breiten Prozessoren mit vielen Kernen das Problem haben, dass der Turbo nicht schnell genug greift und der Task durch den Sheduler des OS bereits einem neuen Core zugeordnet wurde.
 
Candy_Cloud schrieb:
Nachteil dieser Funktion:
Wieder mehr hochfrequente Peaks auf den Kondensatoren der Netzteile. Ist im Prinzip nichts anderes als bei den Grafikkarten.

Also bis zum Netzteil kommen diese Spitzen wohl kaum durch. Genau dafür gibt's ja die viel reaktionsschnelleren Spannungswandler rund um den CPU-Sockel, die mikrosekundengenaue Vorgaben von Intel erfüllen müssen (bei Haswell war ja ein Teil der Spannungswandler sogar offenbar direkt in der CPU) . Am Netzteil kommt das viel geglätteter an - bin kein E-Techniker aber anders kann es ja kaum sein.
 
Fragger911 schrieb:
Windows 7 hat noch Support bis 2020 (Windows 8/8.1 bis 2023) und ist sehr weit verbreitet, nicht nur bei Privaten, gerade auch in Firmen.

Falsch! Windows 7 ist im Extended Support. Es werden seit über einem Jahr keine neuen Features sondern nur noch Sicherheitsupdates bereitgestellt.

Vor allem geht es hier um nichts bahnbrechendes wofür man überhaupt noch bei alten Systemen was anpassen würde. Da einzige was noch passieren könnte, wäre ein Backport für Windows 8.1/Server 2012R2.
 
Zuletzt bearbeitet:
Jesterfox schrieb:
Falsch, Windows 7 ist aus dem normalen Supportzeitraum schon raus und bekommt nur noch Security-Fixes bis 2020.

Das ist immer der schönste Moment im Leben eines jeden MS-Betriebssystems :D
 
Die Diskussion, welche Regelung besser ist, könnte doch ganz einfach damit beendet werden, wenn man im Betriebssystem das State-Verhalten auswählen könnte. Bei optimierter Software wäre es durchaus möglich, dass das Management über die Software effizienter ist.
Der beste Ansatt wäre meiner Meinung nach, wenn es Profile gäbe, sodass man selbst das beste davon auswählen könnte. Entweder auf User-Seite, oder auf Entwickler-Seite.

Bei Android gibt es bei den verschiedenen Kernels teilweise die Möglichkeit, selbdt das Takt-Verhalten zu bestimmen oder zu modifizieren. Dadurch habe ich bei meinem alten Note 2 einiges an Akkulaufzeit herausholen können. Der Normal-Nutzer wird das natürlich nicht nutzen, aber Software-Entwickler könnten damit schon eine gute Grundlage schaffen.
 
Zurück
Oben