Singlecore Turboproblem (nicht nur) beim Haswell-E

[bigred]

copy pasta aus einem anderen Forum:

Q:X99M Killer + i7 5820K: schlechte single core Leistung - Seite 5

"heho,
also ich hab auch vor mit einen 5820K zu holen und bin durch Zufall auf dieses Problem gestoßen. Ist zwar schon etwas alt der Thread, aber vll bringts doch noch was Vor Ewigkeiten hatte ich schoneinmal nach Möglichkeiten gesucht die Energieoptionen von Windows besser einstellen zu können und habe ein paar Kommandos gefunden um zusätzliche Energieoptionen in Windows (7) freischalten zu können. Unter Anderem ist es damit möglich zu definieren ab welcher Last die Kerne hochgestuft, runtergestuft, Kerne geparkt werden etc. Vll kann jemand mit den Optionen etwas rumspielen und schauen ob man so das Singlethreadproblem lösen kann. Mir ist beim durchschauen der Optionen aufgefallen das Windows per default einen Wert von 10% definiert für das Hochtakten. Da rein Rechnerisch, wie Incredible Alk zeigte, beim 5890K bei Singlethreadauslastung die Systemlast nur 6,25% beträgt bzw. 8,3% beim 5820K ist, reicht es vll. ja schon die entsprechende Option auf 6 bzw. 8% zu senken um dem Singlethreadproblem entgegen zu wirken. Am Besten einfach mal mit den Einstellungen spielen und falls es zu Erfolg führt mit uns teilen. Dann kann man daraus vll ein kleines powershell Skript basteln und es allen zur Verfügung stellen.

Die folgenden Befehle einfach in der Windows Komandozeile (cmd) ausführen und danach die Energieoptionen (Systemsteuerung->Energieoptionen-> Energiesparplaneinstellungen ändern->Erweiterte Enerieeinstellungen ändern) öffnen. Unter Prozessorenergieverwaltung sollten dann einige zusätzliche Einstellungsmöglichkeiten auftauchen (zumindest bei mir unter Win7):
powercfg.exe -attributes SUB_PROCESSOR 06cadf0e-64ed-448a-8927-ce7bf90eb35d -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 12a0ab44-fe28-4fa9-b3bd-4b64f44960a6 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 40fbefc7-2e9d-4d25-a185-0cfd8574bac6 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 4b92d758-5a24-4851-a470-815d78aee119 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 7b224883-b3cc-4d79-819f-8374152cbe7c -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 943c8cb6-6f93-4227-ad87-e9a3feec08d1 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 9ac18e92-aa3c-4e27-b307-01ae37307129 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 8f7b45e3-c393-480a-878c-f67ac3d07082 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 0cc5b647-c1df-4637-891a-dec35c318583 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 1299023c-bc28-4f0a-81ec-d3295a8d815d -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 2ddd5a84-5a71-437e-912a-db0b8c788732 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 447235c7-6a8d-4cc0-8e24-9eaf70b96e2b -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 5b33697b-e89d-4d38-aa46-9e7dfb7cd2f9 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 68dd2f27-a4ce-4e11-8487-3794e4135dfa -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 71021b41-c749-4d21-be74-a00f335d582b -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 8809c2d8-b155-42d4-bcda-0d345651b1db -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR a55612aa-f624-42c6-a443-7397d064c04f -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR c7be0679-2817-4d69-9d02-519a537ed0c6 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR df142941-20f3-4edf-9a4a-9c83d3d717d1 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR dfd10d17-d5eb-45dd-877a-9a34ddd15c82 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR e70867f1-fa2f-4f4e-aea1-4d8a0ba23b20 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR ea062031-0e34-4ff1-9b6d-eb1059334028 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR d8edeb9b-95cf-4f95-a73c-b061973693c8 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 984cf492-3bed-4488-a8f9-4286c97bf5aa -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 4d2b0152-7d5c-498b-88e2-34345392a2c5 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 465e1f50-b610-473a-ab58-00d1077dc418 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 7d24baa7-0b84-480f-840c-1b0743c00f5f -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR c4581c31-89ab-4597-8e2b-9c9cab440e6b -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 6c2993b0-8f48-481f-bcc6-00dd2742aa06 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 5d76a2ca-e8c0-402f-a133-2158492d58ad -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 45bcc044-d885-43e2-8605-ee0ec6e96b59 -ATTRIB_HIDE >nul
powercfg.exe -attributes SUB_PROCESSOR 3b04d4fd-1cc7-4f23-ab1c-d1337819c4bb -ATTRIB_HIDE >nul

Gruß"

Vielleicht möchte das ja mal jemand ausprobieren und die Resultate hier posten

 

[nemihome]

Das Punkt ist: Es fahren eh nur einzelne Kerne hoch. Nie alle bei den Haswell-E bei Teillast. Das Problem ist wie gesagt mit Win 10 weniger Stark ausgeprägt. Die Gesamtauslastung spielt eine geringere Rolle.

 

[G3cko]

Zur Not Weise einem alten Spiel einfach im Taskmanager eine begrenzte Anzahl an Cores zu.

 

[nemihome]

Da weist man explizit Kerne zu. Wenn die dann auch für anderes genutzt werden ist es blöd. Aber als Workaround ok.

 

[fdsonne]

Das machts doch aber nicht besser, wenn die Last zu niedrig ist... Sprich die Gesamtload gar nicht über den minimalen Punkt kommt, dass die Hütte überhaupt hochzieht.

Ich hab es jetzt einfach so, dass ich, wenn ich weis, dass ich Leistung brauche, auf Höchstleistung stelle und gut ist. -> kostet mich ganz paar Watt im idle, aber idle ist ja so oder so nicht, wenn Last angelegt wird. In Verbindung mit dem Allcore OC und Multi gleich auf allen Cores tuts dieser Workarround durchaus. Sowohl in W7 als auch W8.1 -> W10 noch nicht probiert.

 

[G3cko]

Das machts doch aber nicht besser, wenn die Last zu niedrig ist... Sprich die Gesamtload gar nicht über den minimalen Punkt kommt, dass die Hütte überhaupt hochzieht.

Ich hab es jetzt einfach so, dass ich, wenn ich weis, dass ich Leistung brauche, auf Höchstleistung stelle und gut ist. -> kostet mich ganz paar Watt im idle, aber idle ist ja so oder so nicht, wenn Last angelegt wird. In Verbindung mit dem Allcore OC und Multi gleich auf allen Cores tuts dieser Workarround durchaus. Sowohl in W7 als auch W8.1 -> W10 noch nicht probiert.

Doch, dass zuweisen weniger Cores hilft sehr wohl. Im Cinebench taktet die CPU im Single thread Test fast durchgehend mit 1.2ghz und ab und an mit 3.0ghz. Mit Zuweisung liegen dauerhaft 4.2ghz an.

 

[nemihome]

Sobald man das Spiel mit mehreren Anwendungen macht wird es aber schnell lästig, weil man die Kerne explizit zuweist.

 

[G3cko]

Sobald du mehrere Anwendungen hast, hast du ohnehin genug Last und das Problem erübrigt sich. Bis auf den benchmark merke ich im Alltag nichts.

 

[Brainorg]

Ich habe glücklicherweise keine Anwendung die so auf SC ausgelegt ist.
Im Moment lasse ich alles auf default laufen und merke keine Nachteile.
Aber gut zu hören das bei WIN10 das ganze weniger ausgeprägt ist.

 

[Bucho]

Ich habe unter Win7 mal die Erweiterung probiert die @bigred aus Post 91 vorgeschlagen hat.

Also es kommen dann in der Energieverwaltung unter Prozessor jede Menge Unterpunkte die auch alle eine kurze Beschreibung dabei haben. Habe mich mit denen herumgespielt, aber das Problem konnte ich damit nicht lösen.
Mit Höchstleistung taktet die CPU voll hoch, aber sobald ich mit dem Energiesparplan "Höchstleistung" den Wert für minimalen CPU Takt von 100% auf 5% runter setze (oder auch auf irgendeine % Zahl dazwischen, z.B. auch 99%) taktet sie bei Last auf einem Kern nicht mehr voll hoch.
Zum Test habe ich SuperPI Mod daneben laufen lassen und mich mit den Einstellungen gespielt.

Sehr eigenartig das ganze. Gut ich habe jetzt wohl auch wenig Software die nur einen Kern auslastet bzw. wenn dann ist es wohl egal ob der Kern dann mit 3.3, 3.6 oder 4+ GHz rennt, aber unschön ist es schon.

 

[cHio]

Seit Windows 10 habe ich was die Thematik angeht überhaupt keine Probleme mehr.

 

[Phantomias88]

Seit Windows 10 habe ich was die Thematik angeht überhaupt keine Probleme mehr.

Sehr schön, die Richtung scheint zumindest mal zu stimmen!
Setzt die Segel, Männer!

http://abload.de/img/hwinfo64_x264._tm8fprv.jpg

 

[nemihome]

Sobald du mehrere Anwendungen hast, hast du ohnehin genug Last und das Problem erübrigt sich. Bis auf den benchmark merke ich im Alltag nichts.

Jein, es ist immer der letzte Kern da Problem, der unzureichend ausgelastet ist. Bei Herr der Ringe Online mit Windows 7 merkt man das gut z.B. - kommt halt auch noch drauf an, ob Haswell-E oder nicht.

 

[nemihome]

Seit Windows 10 habe ich was die Thematik angeht überhaupt keine Probleme mehr.

Jo, zumindest weniger.

 

[lll]

Vielen Dank für dein erstelltes Thema H_M_Murdock

Danke deiner Anleitung funktioniert der Stromsparmodus perfekt - Windows7 & Haswell-E

Ich hoffe ich konnte dazu beitragen, dass das Thema bei den Suchmaschinen weiter bei den ersten Ergebnissen bleibt.

Das mit dem Stromsparmodus war bei mir schon vorher eine halbe Odyssee, erst wenn ich bei den RAM von 2666MHz auf 2600MHz wechselte, konnte ich den 100er Strap wieder nutzen, mit dem 125er Strap funktionierte der Stromsparmodus nicht - kurios.

Genug von mir, Vielen Dank H_M_Murdock.

MfG lll

 

[jk123]

Hallo,

ich grab das Thema hier nochmal aus. Die Problematik trifft definitiv auch stark auf Windows 10 zu.
Mein 5930K mit 42er Multi reagiert bei einem Durchlauf vom Realbench Gimptest definitiv stark unterschiedlich, je nach konfiguriertem Energiesparplan.

Hier mit "Ausgewogen":



Hier mit "Höchstleistung" (minimaler Leistungszustand auf 5%):



Die Counter wurden jeweils vor dem Run zurückgesetzt (HWInfo).
Am deutlichsten macht es wohl die Average Core Clock.
Ein Vergleich zu anderen Windows Versionen habe ich nicht da ich mein System nach dem Aufbau nur mit 10 betrieben habe.
Der Unterschied beträgt mal eben knapp 20000 Punkte im RB Image Editing.

Gruß
jk

 

[Gelöschtes Mitglied 172838]

Ich bin jetzt vom i5 5820K/i7 5960X zum i5 6600 (ohne K) gewechselt. Und was soll ich sagen, in alltäglichen Dingen ist der i5 schneller als der 8- und 6-Kerner.
Der i5 taktet schnell auf 3,8 Ghz hoch und agiert wesentlich aggressiver. Dadurch starten Programme schneller und Webseiten laden schneller. Spür- und messbar. Kein gewaltiger Unterschied natürlich, aber dennoch irgendwie ärgerlich wenn man bedenkt, dass das doch die High End Plattform sein soll.

So lange man die Mehrkerne nicht dauerhaft nutzen kann sollte man meiner Meinung nach definitv Abstand von X99 nehmen (von wegen "Zukunftsfähigkeit und so").

 

[cHio]

Bei Skylake und Windows 10 kommt ja noch hinzu, dass mittlerweile die CPU die Frequenz regelt und nicht mehr Windows. Ein großer Vorteil.

 

[G3cko]

In fast jedem aktuellen bench ist x99 flinker. Die Turbo Problematik merkt man eher in älteren Anwendungen. Hier agiert skylake deutlich agiler.

Das Turbo Problem merke ich nur in einer Anwendung und da hilft das festpinnen auf 2 Kerne massiv.

Je mehr Zeit vergeht desto mehr verschwindet das Problem in der bedeutungslosigkeit. Mit dx12 dürft x99 sich dann klar von den skylake quads absetzen.

Skylake-e wird sicherlich eine interessante Plattform ohne die Probleme und einfacherem oc. Nur eben 2 Jahre zu spät.

 

[eagle*23*]

hab jetzt auch mal auf Höchstleistung gestellt. Im idle geht er ja trotzdem runter mit Takt und dann ist der Mehrverbrauch glaub minimal.

 

[nemihome]

Unter Teillast ist der Verbrauch dann deutlich höher. Aber besser wird's mit der Plattform nicht mehr. Man muss also einen Tod sterben. Mein nächster (also bei neuem Board) wird wohl auch kein E - mal sehen.

 

[eagle*23*]

oh ok nix Adler goes green. Sky-E wird sicher wieder besser dann. Broadwell E wird denk gleiches Problem haben da ja auch noch Spannungsversorgung in der CPU

 

[fdsonne]

Dreh doch einfach den Energiesparplan bevor du irgendwas leistungsfressendes machst, entsprechend deinen Wünschen um?
Geht doch mit ein paar Klicks... Während der normalen Arbeit merkt man doch so oder so keinen Unterschied. Und wenn du ne Anwendung hast, die da massiv von profitieren kann, dreh auf volle Kanne und los gehts...

Bei mir klebt der Turbo quasi ausschließlich auf vollem Takt. Zwischen Ausbalanciert und Höchstleistung liegen in etwa 30-40W absoluter Unterschied. Das ist aus meiner Sicht vernachlässigbar. Die Hütte säuft so oder so extrem viel Strom. Ob da nun 250W "idle" oder 290W "idle" stehen. Das macht den Kohl nicht fett

Mit Höchstleistung hast du effektiv das Problem auch nicht wirklich, da der Takt dann nicht mehr schwanken sollte. Zumindest nicht mit OC, sprich wenn du den Turbo über alle Cores gleich setzt.

 

[Gelöschtes Mitglied 172838]

Sandy-E hatte das Problem auch schon. Und wenn sie es nicht beim Nachfolger angegangen sind, bin ich was Skylake-E angeht eher pessimistisch. Vielleicht wissen die gar nichts von dem Problem.

 

[cHio]

Bei Broadwell-E wirds genau so sein wie bei den Generationen zuvor. Skylake beherrscht Intel Speed Shift unter Windows 10 und damit ist das Problem sowieso vom Tisch.

 

[nemihome]

@justINcase Die wollen eher nichts davon wissen. Bei Asrock konnte man das lt. deren Aussage nicht reproduzieren. Angeblich hat man es an Intel weitergeleitet und danach kam dann trotz mehrfacher Rückfrage nie eine Rückmeldung.

Die Presse schweigt sich auch aus und testet quasi komplett ohne Energiemanagement, sonst hätten die Tester solche Probleme in Benchmarks auch. Die c't als recht renommiertes Magazin hat sich zumindest die Zeit für ein paar Antworten genommen. Auf die Frage warum das noch nie in Tests aufgefallen ist kam aber auch nur, dass man für derart aufwendige Tests heute keine Zeit mehr habe.

Ergo klopfen sich alle für maximale Energieeinsparung im Teillast / Idle Bereich und tolle Benchmarks auf die Schulter, was aber zusammen nicht funktioniert. Zumindest nicht mit dieser Plattform.

 

[fdsonne]

Neja, wie gesagt, das Problem ist nicht wirklich die Hardware, viel eher ist die Last zu gering... Wenn ein Thread bei 12-16 vorhandenen Last hat, dann ist das nunmal nur 1/12tel oder 1/16tel. Gemessen auf das Gesamte sind das nichtmal 10%.
Und scheinbar spuckt auch das OS massiv in die Thematik mit rein, denn es steuert ja in gewisser Weise, welcher Takt da bei rauskommen soll. Die Logik dabei ist aber wohl einfach mehr so ganz zeitgemäß bei breiten CPUs. Ebenso ist die Schwelle wohl unbekannt, welche dafür sorgt, dass der Takt hoch zieht. Kommt dann noch dieses Thread hin- und herschubsen dazu, dann liegt die Last pro Hardwarethread nochmal unterhalb von besagten 10%. Nämlich im schlechtesten Fall bei 1/12tel bzw. 1/16tel unterhalb. Da bliebt effektiv nicht mehr viel übrig. Und das OS "denkt", da ist keine Last da, also ziehen wir den Takt nicht hoch...

Entgegenkommen kann man dem eigentlich effektiv nur, wenn man die Steuerlogik anpasst. Oder aber das Problem dediziert in Hardware löst.

Nimmt man es genau, haben auch andere CPU Modelle ein derartiges Problem. Nur eben weit weniger ausgeprägt. Denn bis der Turbo zündet, vergeht Zeit Das ist Zeit, in der die CPU schon rechnet, aber der Takt noch unten ist. Ggf. durchgeht der Turbo sogar ALLE Stufen bis er auf höchstem Takt angekommen ist. Um so kürzer deine Berechnung absolut, desto mehr Zeit verschwendest du bei dem Thema, wenn die CPU nicht dauerhaft mit vollem Takt läuft.

Technisch gesehen ist der Turbo auch so oder so für den Hintern... Denn er soll ja gerade diese Lastspitzen abfedern... Taugt aber nicht sonderlich, wenn er zu behebig agiert. Besser wäre es für die Performance, wenn die CPU genau andersrum agiert. Sprich vollen Takt immer anliegend. Und bei "Engstellen" dann stückweise den Takt runter. Ähnlich wie es NV und AMD im GPU Bereich aktuell fabrizierten, wenn man ins Power und/oder Temperaturlimit rennt. Leider steht dem halt dann wieder das Verbrauchsthema im Weg...

 

[Tzk]

Entgegenkommen kann man dem eigentlich effektiv nur, wenn man die Steuerlogik anpasst. Oder aber das Problem dediziert in Hardware löst.

Das ist dann (mal wieder) Microsofts Schuld, da sie anscheinend die Gesamtauslastung und nicht die Auslastung pro Kern überwachen, um den Turbo zu zünden.
Eigentlich traurig, da breite Prozessoren ja nicht erst seit gestern existieren...

 

[fdsonne]

Bei Broadwell-E wirds genau so sein wie bei den Generationen zuvor. Skylake beherrscht Intel Speed Shift unter Windows 10 und damit ist das Problem sowieso vom Tisch.

Da wäre ich mir gar nicht ganz so sicher... Denn selbst in Hardware löst man das Grundproblem ja nicht.
Solange das OS die Threads, welche Last erzeugen schön hin und her schubst und die Hardware eine gewisse Mindestlast benötigt, damit der Turbo zündet, wird sich wohl fast nix ändern. Schlimmer noch. Wenn die Cores alle einzeln takten können verschlimmert sich das Problem sogar noch. Haswell-E taktet ja die Cores einzeln. Das dürfte bei den Nachfolgern nicht anders sein...

Ich bin aber ehrlich gespannt auf den Zen Prozessor. Acht Cores und 16 Threads könnten da die gleiche Problematik hervorrufen Mal schauen, wie AMD das löst.

Ergo klopfen sich alle für maximale Energieeinsparung im Teillast / Idle Bereich und tolle Benchmarks auf die Schulter, was aber zusammen nicht funktioniert. Zumindest nicht mit dieser Plattform.

Das ist richtig... Man muss halt nur wissen, dass die Tests so oder so nur gewisse Bereiche beleuchten. War doch eigentlich immer so... Wer benches ließt, sollte wissen, das die Zahlen dort nur in den Benches gelten und bestenfalls eine Tendenz auf dem gesamten Markt bedeuten, keinesfalls aber explizit auf ALLE Bereiche anwendbar sind.
Lasttests mit energiespar Einstellungen zu tätigen ist halt eher kontraproduktiv. Denn es soll ja die Leistungsfähigkeit gemessen werden, nicht aber das, was in der Praxis real anliegt... Schon allein die Benchmarkauswahl, vor allem im CPU Bereich zeigt, dass wir weit ab der Realität sind. Denn was testet man denn da heute? Neben Audio/Videoencoding und irgendwelchem Rendering Zeugs, was teils wirklich massiv von MT profitiert, ist da wenig praxisrelevantes dabei...

Das ist dann (mal wieder) Microsofts Schuld, da sie anscheinend die Gesamtauslastung und nicht die Auslastung pro Kern überwachen, um den Turbo zu zünden.
Eigentlich traurig, da breite Prozessoren ja nicht erst seit gestern existieren...

Kommt drauf an, was man überhaupt "messen" kann
Ich wäre mir gar nicht so sicher, dass man da dediziert in Software so viele Daten auswerten kann. Schon die Diagramme im Taskmanager zeigen, dass MS da nur begrenzt was tätigt bzw. tun kann... Denn der Taskmanager zeigt auch "nur" eine erechnete Last über eine gewisse Zeit in Form einer Auslastungskurve an. Keinesfalls aber die reale Last im CPU Kern.
Rein technisch kennt der Prozessorkern eigentlich nur Last oder keine Last. Der Taskmanager nimmt nun einfach diese beiden Zustände und setzt sie in ein Verhältnis zu einer Zeiteinheit. Bspw. eine Sekunde. -> zeigt dann am Ende an, dass in der Zeit von einer Sekunde so und so viel Prozent Last anlagen. Dabei macht er nichtmal einen Unterschied zwischen Last auf den ALUs und Last auf der FPU. Beides geht heute gleichzeitig... Dem Taskmanager ists aber völlig hupe. Last ausschließlich auf den ALUs ist Last im Taskmanager und Last ausschließlich auf den FPUs ist ebenso Last im Taskmanager. Beides zusammen macht die Kurve nicht größer, obwohl die reale Last deutlich höher wäre...

Die Frage ist also eher, wie will man das OS seitig überhaupt angehen?
Aus meiner Sicht ist der Fehler, dass hier das OS die Steuerung übernehmen soll(te)... Das ganze gehört dediziert in Hardware implementiert. Denn die Hardware selbst sollte schon wissen, was "Last" bedeutet und was nicht... Eventuell kann man das für die Zukunft mit gewissen Einstellungen paaren, die man im UEFI dann setzt. Bspw. eine konservative, die ähnlich der heutigen agiert (eben etwas behebig -> spart dann halt Strom) oder eine aggresive, die bei jedem Deut "Last", egal auf welcher Recheneinheit, den Takt bedingungslos ans Maximum treibt... (kostet halt Strom, dafür schneller)

 

[G3cko]

Natürlich wird skylake-e das Problem nicht mehr haben. Das ist doch gerade das Ziel von speedshift...


Intel hat erkannt, das dass hochtakten zu lange dauert und das verwalten des energiemanagements über das OS nicht gut funktioniert. Beides wird sich ändern.

- - - Updated - - -

Natürlich wird skylake-e das Problem nicht mehr haben. Das ist doch gerade das Ziel von speedshift...


Intel hat erkannt, das dass hochtakten zu lange dauert und das verwalten des energiemanagements über das OS nicht gut funktioniert. Beides wird sich ändern.