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.
NewsSpeed Shift: Intel-Technik verringert Latenz bei Touch-Bedienung
Ein eigener Test mit verschiedener Software und Peripherie wäre wünschenswert. Aber gut, bei diesem Thema gibt es keine passenden Affiliate-Peodukte die man posten könnte. Dann bleibt man doch beim Kerngeschäft: Gehäuse. Da gibt's nicht viel falsch zu machen und die Preise sind hoch.
PS: Habe mir von SpeedShift ehrlich gesagt mehr erhofft, weil ich dachte es wird DAS Kaufargument für die Skylakes. So hat man eigentlich keinen Grund aufzurüsten. Naja, bei meinen Notebook habe ich zwar Skylake und ich arbeite viel mit Office und der Adobe Collection, aber habe ehrlich gesagt keinen Unterschied bemerkt.
meiner Meinung nach müsste man "einfach nur" das Springen auf Vollast aus dem tiefstmöglichen Schlafzustand und zurück so schnell wie möglich machen und kann sich alle Zwischenstufen sparen.
Also der Gedanke geht meines Erachtens nach in die richtige Richtung.
Deshalb hat es mich auch sehr verwundert zu sehen, dass die bisherigen Prozessoren da unter Windows bis zu 100ms (eine Zehntel Sekunde, wtf) brauchen um auf Vollgas zu schalten. Dachte das geschieht schneller (der Prozessor könnte ja).
Nach meinem Gefühl sind die Stufen nach oben viel zu zurückhaltend.
Andererseits hat Microsoft die statistischen Daten für vielerlei Workloads auf dem Tisch und gute Leute. Aber dennoch ;-)
Habe mich jedenfalls anlässlich der SpeedShift-Einführung entschieden, mir für 0,2W mehr Idle-Verbrauch den Idle-Takt auf 1,6 Ghz zu gönnen ;D
(Und ThrottleStop für optionalen Turbo bis zum Zimmerbrand ;-))
Im früheren Artikel zu SpeedShift wurde schon beschrieben, dass die Reaktionszeit stark vom CPU Governor abhängt und es da verschiedenste Strategien gibt, wie die CPU gesteuert wird.
Der Governor von Windows wird darauf angepasst sein, dass im Hintergrund immer irgendwas läuft und CPU Zeit haben will, aber nicht viel Laufzeit benötigen. Entsprechend wäre es da Unsinn die CPU jedes mal auf den maximalen Takt hoch zu scheuchen, auf das die CPU auf hohem Takt hauptsächlich leer läuft und damit sinnlos elektrische Energie verpulvert. Entsprechend wird da wohl eher ein konservativer Governor verwendet werden, der versucht die eingestellte Taktfrequenz so zu Steuern, dass der Leerlauf möglichst klein wird.
Wobei Windows wie andere Betriebssysteme auch verschiedene Governor einstellen kann, die das Verhalten deutlich beeinflussen können.
Das ist klar, hatte ich ja selber in diesem Thread schon geschrieben ;-) Meine Aussage war halt nun, dass mir die Default-Einstellungen zu lasch vorkommen.
... Entsprechend wäre es da Unsinn die CPU jedes mal auf den maximalen Takt hoch zu scheuchen, auf das die CPU auf hohem Takt hauptsächlich leer läuft und damit sinnlos elektrische Energie verpulvert. ...
Na ja, am effizientesten wäre es aber schon, wenn die CPU die anstehenden Aufgaben mit Maximaltakt erledigt und sich dann sofort wieder schlafen legt. Das bedingt aber kurze oder vollflexible Zeitscheiben und eine minimale Aufwach- und Einschlafphase. Bei heutigen Mehrkern-CPUs ist noch mehr Flexibilität möglich in Bezug auf die Lastverteilung auf mehrere Kerne.
Die Govenor steuern ja, wie schnell in die tiefen C-States gegangen bzw. von diesen wieder hochgefahren wird.
Das Hauptproblem heutzutage sind die unterschiedlichen Aufwachzeiten aus den verschiedenen C-States. Hier liegt das größte Optimierungspotential. Siehe das hier, das Fazit fast es gut zusammen.
die meisten Hintergrundanwendungen haben ja leider nicht die Angewohnheit nur mal fix Daten zu verarbeiten und gut. Oftmals sind es eher so Anwendungen, die mal schauen ob es im Netz neue Daten gibt (Email, Updates, Werbung,...) und/oder Zugriff auf den Festspeicher (Logfile schreiben, Hintergrundüberprüfung irgendwelcher Dateien, ...). Damit hat die CPU wirklich nur wenig zu tun und wartet trotzdem aktiv darauf, dass die angefragten Daten eintümpeln. Bei der Vielzahl an Hintergrunddiensten die sich immer so mit installieren und vor allem der beschissenen Qualität*. Die CPU für diese Zeit auf voller Last laufen zu lassen ist unsinn, die CPU aggressiv wieder in tiefere C-States zu schicken auch, dann der Governor kann nicht/kaum unterscheiden ob die Anwendung nur ein Hintergrunddienst war, oder aber der Nutzer das gerade fix erledigt haben will.
Was die Aufwachzeiten angeht, dass hatte vor einiger Zeit (1Jahr+) die c't mal probiert und sich mit nem Oszi an die Versorgungsspannung einer modernen (Intel) CPU gehängt. Da ist für typische Anwendungsfälle die Zeit zum Durchlaufen der C-States überhaupt kein Problem. Wenn ich mich recht entsinne konnte die CPU da bei Nutzung eines einfachen Texteditors ohne Hintergrunddienste immer in die tiefsten C-States wechseln, hat immer wieder in minimal notwendigen C-States gewechselt um zu schauen ob es etwas zu tun gibt und nur aller X. dieser Zyklen musste die CPU wirklich mal aufwachen um die Eingabe zu verarbeiten. Das alles ohne merkliche Verzögerung für den Nutzer und erst bei sinnlosem Buttonsmashing ist die CPU nicht mehr komplett entschlummert. Entsprechend behaupte ich, dass das Wechseln der C-States mittlerweile fix genug ist. Selbst ohne SpeedShift!
Für mich lieft der groß vermarktete Vorteil damit beim weniger konservativem Profil beim Wechseln zwischen den C-States.
*OfTopic: Eine der besten Nebeneffekte beim Umstieg auf Linux, es gibt ein Großteil der beschissenen Software nicht für PinguinOS
Edit: Die verlinkte Seite ist interessant, was jedoch Latenzen angeht sind die >250µs die genannt werden um von C6 und tiefer bis zu C0 zu kommen nicht von Bedeutung. Bildschirme werden meist mit 60Hz angesteuert. Entsprechend macht das Aufwachen keine 2% der Zeit aus, die es für den Bildwechsel braucht. Das ganze wäre erst störend, wenn sinnlos oft zu C6 und weiter hinunter gewechselt werden würde, obwohl Arbeit ansteht /anstehen könnte. Dann summiert sich der Zeitbedarf auf und kostet entsprechend Leistung. So doof stellt sich aber normal kein produktiv eingesetzter Governor an (experimentelle Governor gibt es für einige Android Roms und Linux, das ist aber ein Schuss ins Bein), die tauglichen Profile sehen alle ein Delay vor, die die CPU halbwegs aktiv verbringt um auf weitere Ereignisse spontan reagieren zu können.
aber im Prinzip arbeiten auch Hintergrundprozesse stoßweise, wie jede Software. Ein Programm läuft und soll etwas tun, und zwar so schnell wie möglich. Wartet es auf irgendwas, z.B. IO, kann es derweil pausieren und die CPU kann schlafen. Geht's dann weiter, wacht sie wieder auf. Und das kann auch gern sehr oft in einem kleinen Zeitintervall passieren.
Und bezogen auf den Edit (nicht übersehen: der Artikel sit auch schon etwas älter und sollte das exemplarisch verdeutlichen): eben deswegen postuliere ich ja, dass es ideal wäre, wenn die CPU zwischen deep sleep und full power in minimalster Zeit wechseln könnte. Die mehreren Stufen aktuell sind ja genau dem Kompromiss Energie sparen vs. Performance geschuldet.
Das hat mit "aktuell" nix zu tun. Das ist ein Problem der Regeltechnik im allgemeinen. Zustandswechsel kosten Zeit und Energie, regelt man zu fein erreicht man irgendwann den Punkt, indem der Overhead der Regelung Überhand nimmt. Je besser/schneller Zustandswechsel funktionieren, desto geringer wird der Overhead, am Sachverhalt selbst ändert sich jedoch nichts.
Zudem, wenn die Regelung fix erfolgen soll muss die CPU kurzfristig immer wieder nachschauen ob die Inputbuffer etwas von Interesse enthalten. Je häufiger das Ding prüft, desto weniger ist es im Tiefschlaf.
Hallo Piktogramm, du hast Recht mit dienen Ausführungen, deswegen ist ja genau dort noch viel Verbesserungspotenzial vorhanden. Eben sowohl was die Geschwindigkeit des Zustandswechsels betrifft, als auch die Regelkreise, die das steuern.
Ich behaupte, wir sind da noch nicht am angesprochenen Punkt. Bei heutigen Prozessorgeschwindigkeiten im Gigahertzbereich sollte es doch schaffbar sein, im Nanosekundenbereich (~100ns = 100 Taktzyklen bei einem GHz) von Deep Sleep auf Volllast zu kommen. Und wenn dazu in der CPU ein eigener, separat getakter Teil existiert, der nur für diese Regeleung zuständig ist.
Na ja, wir werden sehen, was in der Richtung in Zukunft noch so kommt ;-).
Sorry, sobald es um das Thema UI oder Distributionskompatibilität geht, sind sämtliche Linux-Distributionen und deren Software nach wie vor groß dabei mit Schrott-Software. Richtig groß.
Deshalb wäre ich mit deiner Aussage vorsichtig. Das ist kein Klischee sondern meine bittere Erfahrung.
Ich benutze sowohl Win 10 als auch Ubuntu und sei versichert: Ich wollte nicht nur einmal den Ubuntu-Machern direkt ins Gesicht hauen, mal politisch inkorrekt ausgedrückt.
"Tolle Software" (im Vergleich zu Windows oder Mac) ist sicher kein Grund für irgendeine Linux-Distribution*
*es sein denn man freut sich schon darüber, dass die mitgelieferte Fotoanwendung jetzt auch für das Dritte UI-Framework geported wurde und manchmal fehlerfrei drucken kann.
Noch ein Beispiel: Ausgerechnet für git (die Versionsverwaltung von Torvalds - die Quasi-Industriestandard und beim Kernel (!) verwendet) gibts für Mac und Windows eine größere und hochwertigere Auswahl an grafischen Tools als für Linux**. Das sagt eigentlich schon alles.
** Beispiel das beliebte SourceTree von Atlassian: Die Entwickler haben nach eigener Aussage derzeit nichtmal Pläne für eine Linux-Version..
Ergänzung ()
ErichH. schrieb:
eben deswegen postuliere ich ja, dass es ideal wäre, wenn die CPU zwischen deep sleep und full power in minimalster Zeit wechseln könnte. Die mehreren Stufen aktuell sind ja genau dem Kompromiss Energie sparen vs. Performance geschuldet.
Die CPU kann ja technisch auch im Mikrosekundenbereich hochtakten (hattest ja ebenfalls was in die Richtung geschrieben).
Es sind die Betriebssysteme, die für die insgesamt langen Upscaling Zeiten sorgen. Meistens wohl gewollt.
Daher auch meine Aussage: Mir kommen die Zeiten teils zu lange vor. Wie schon geschrieben, Idle von 800 Mhz auf 1,6 Ghz fix zu setzen kostet kostet ~0,2 Watt pro Zeiteinheit, auf meinem mobilen i7 Quadcore. Warum also übervorsichtig sein, wenn man spekulativ den Takt anhebt - das Upscaling über alle P-States über 100ms ist zu vorsichtig in meinen Augen, für die klare Mehrheit der Szenarien.
Zumal ein Teil der 0,2 Watt ja bei Nutzung wieder kompensiert wird, weil der Sweetspot für Rechenleistung pro Joule (bezogen auf Dauerlast) eher Richtung 3 Ghz liegt. (Bei einem Sandy Bridge um die 3,6 Ghz - höher als ich geschätzt hätte).
