Sind diese Dinge in der Theorie machbar?
- Ersteller HelixUltra
- Erstellt am
HelixUltra
Fleet Captain Special
- Mitglied seit
- 21.11.2008
- Beiträge
- 254
- Renomée
- 9
Moin Leute, ich bewundere eure Fähigkeiten was die Analyse von CPUs und GPUs angeht aufs äußerste! Ganz dickes Lob an alle, die hier immer fleißig mitgrübeln, ist echt spannend mitzulesen.
So, nun habe ich mal ein paar Fragen, die nur ihr mir beantworten könnt. Hauptsächlich spielen sie auf energetische Effizienz ab, weil die meisten Rechner ohnehin nur im IDLE fahren.
1) Cache dynamisch deaktvieren
Wenn ich mir so die DIE Shots von Phenom2, Core i und Konsorten anschaue, dann denke ich immer daran, ob es wohl möglich ist, die Caches dynamisch zu deaktivieren, um nochmals Strom zu sparen. Ich dachte mir das beim Phenom in z.B. 3 Stufen, 2MB, 4MB und 6MB. Damit sollten gerade beim nichts tun doch einiges gespart werden, da viele Leckströme und der generelle Verbrauch sinkt.
Zu der Idee kam ich über die Cache beschnittenen Versionen ala X4 810, oder noch kleinere Modelle wie Neo etc.
2) Throtteling zum Energiesparen nutzten
Wäre es möglich das Throttleling(richtig geschrieben?) zum Strom sparen zu nutzten? Hier dachte ich speziell an Laptop, die dann einfach auf 800MHz absenken mit C´n´C, und dann weitere Takte auslassen. ( Die Idee entstammt der Hitzedrosselung des P4) Mit sowas könnte man doch sicherlich gerade Standbye Zeit verlängern, oder beim Tippen eines Worddokuments ne Menge sparen. Was meint ihr?
3) Per Prozessortreiber Workloads besser verteilen?
Meine Idee: per Treiber (ähnlich und inspiriert vom Dualcore Optimizer) die Lasten optimal auf 3 und mehr Kerne aufteilen. Gekoppelt mit intelligienter Taktung der Kerne, also Unabhänigkeit der Kerne unter einander, dürfte man sicherlich auch was sparen können, wenn man einen oder zwei ganze Kerne weitestgehend schlafen legt, und nur noch auf zweien weiter arbeitet. Hier sollten dann auch die Ideen 1) und 2) mit einwirken.
klappt oder klappt nicht?
4) Fusion 4all
Ebenfalls per Treiber könnte man die Fusion Idee für alle umsetzen. Entweder über Profile im Catalyst, oder eine Analyse bei der ersten Codeausführung wird dieser überprüft, und je nach Bedarf die Grafikkarte mit befeuert. Denke hier an Video/Audio Coding, Filme und die Beschleunigung des Codec-Container und Formatdschungels sowie Sachen wie Flash. In meiner Idee sollte es dann aber schnuppe sein, ob die Anwendung für sowas ausgelegt ist oder nicht. Ist ein klar programmiertes Stück Software wie ein Videocodec für die Graka oder nur die CPU vorhanden, greift der Mechanismus nicht.
Also, was sagt ihr zu meinen Idee? Ich möchte ehrliche Einschätzungen, aber keine Sachen wie "Geht nicht!" oder "Wieso sollte man das machen". Wenn, dann mit Begründung. Los gehts, ich freu mich auf eure Antworten
So, nun habe ich mal ein paar Fragen, die nur ihr mir beantworten könnt. Hauptsächlich spielen sie auf energetische Effizienz ab, weil die meisten Rechner ohnehin nur im IDLE fahren.
1) Cache dynamisch deaktvieren
Wenn ich mir so die DIE Shots von Phenom2, Core i und Konsorten anschaue, dann denke ich immer daran, ob es wohl möglich ist, die Caches dynamisch zu deaktivieren, um nochmals Strom zu sparen. Ich dachte mir das beim Phenom in z.B. 3 Stufen, 2MB, 4MB und 6MB. Damit sollten gerade beim nichts tun doch einiges gespart werden, da viele Leckströme und der generelle Verbrauch sinkt.
Zu der Idee kam ich über die Cache beschnittenen Versionen ala X4 810, oder noch kleinere Modelle wie Neo etc.
2) Throtteling zum Energiesparen nutzten
Wäre es möglich das Throttleling(richtig geschrieben?) zum Strom sparen zu nutzten? Hier dachte ich speziell an Laptop, die dann einfach auf 800MHz absenken mit C´n´C, und dann weitere Takte auslassen. ( Die Idee entstammt der Hitzedrosselung des P4) Mit sowas könnte man doch sicherlich gerade Standbye Zeit verlängern, oder beim Tippen eines Worddokuments ne Menge sparen. Was meint ihr?
3) Per Prozessortreiber Workloads besser verteilen?
Meine Idee: per Treiber (ähnlich und inspiriert vom Dualcore Optimizer) die Lasten optimal auf 3 und mehr Kerne aufteilen. Gekoppelt mit intelligienter Taktung der Kerne, also Unabhänigkeit der Kerne unter einander, dürfte man sicherlich auch was sparen können, wenn man einen oder zwei ganze Kerne weitestgehend schlafen legt, und nur noch auf zweien weiter arbeitet. Hier sollten dann auch die Ideen 1) und 2) mit einwirken.
klappt oder klappt nicht?
4) Fusion 4all
Ebenfalls per Treiber könnte man die Fusion Idee für alle umsetzen. Entweder über Profile im Catalyst, oder eine Analyse bei der ersten Codeausführung wird dieser überprüft, und je nach Bedarf die Grafikkarte mit befeuert. Denke hier an Video/Audio Coding, Filme und die Beschleunigung des Codec-Container und Formatdschungels sowie Sachen wie Flash. In meiner Idee sollte es dann aber schnuppe sein, ob die Anwendung für sowas ausgelegt ist oder nicht. Ist ein klar programmiertes Stück Software wie ein Videocodec für die Graka oder nur die CPU vorhanden, greift der Mechanismus nicht.
Also, was sagt ihr zu meinen Idee? Ich möchte ehrliche Einschätzungen, aber keine Sachen wie "Geht nicht!" oder "Wieso sollte man das machen". Wenn, dann mit Begründung. Los gehts, ich freu mich auf eure Antworten
Bin zwar hier sicher keiner der Obergurus, aber ich bedank mich trotzdem mal
Nagel mich nicht fest, aber soweit ich weiß, hat das Bulldozer bereits für den L3.
Umgesetzt wird das dadurch, dass der Cache entsprechend aufgeteilt wurde (Ich glaube, es waren sogar 2MB Blöcke wie in deinem Beispiel.) und jeder Block per Power-Gating ein- und ausgeschaltet werden kann.
Jein, Throttling spart zwar Energie, aber der viel wichtigere Aspekt beim Heruntertakten ist das Absenken der Versorgungsspannung. Der Vorteil des Throttling ist hauptsächlich, dass man es zeitlich sehr feingranular steuern kann im Gegensatz zum "normalen" Frequency-/Voltage-Scaling.
Das ist normalerweise Aufgabe des Schedulers. In dem Bereich gibt es unzählige Forschungsarbeiten. Ich habe für die Uni z.B. mal an einer Modifikation des Linux Schedulers gearbeitet, bei dem es darum ging Scheduling, Task-Migration und Frequency-Schaling anhand von Task-Aktivitäts-Vektoren (diese Vektoren beschreiben die Charakteristik des Tasks, also wie häufig er welche Funktionalen Einheiten benutzt) zu steuern. Ziel dabei war es Hotspots durch einseitige Belastung einer bestimmten Funktionseinheit zu vermeiden und die Performance zu bessern, indem man z.B. nicht zwei speicherlastige Threads zusammen scheduled. Bei CPUs mit Multi-Threading gibt's da sogar noch mehr zu beachten, da sich dann ja mehrere Threads die gleichen Resourcen teilen müssen.
Was die Konsolidierung von CPUs, Speicher oder ganzen Rechnern angeht, gibt es das zum Teil bereits schon. In vielen Rechenzentren, wo mit virtuellen Maschinen gearbeitet wird, wird das benutzt. Man migriert also ganze VMs von wenig ausgelasteten Rechnern und schaltet dann einige ab. Hier an der Uni wurde so etwas ähnliches für Arbeitsspeicher gemacht. Wenn nur ein Teil des RAMs benutzt wird, werden die Daten auf ein Teil der Module verschoben und der Rest abgeschaltet. Für CPUs wird das vermutlich auch gehen, wobei mir dazu gerade kein Beispiel einfällt.
Das ist eher unwahrscheinlich, denn CPUs und GPUs haben sehr unterschiedliche Architekturen, so dass Code, der für eine CPU entwickelt wurde auf einer GPU extrem langsam wäre (vorausgesetzt er läuft überhaupt, was normalerweise nicht der Fall ist). Selbst bei OpenCL, dass sowohl CPUs als auch GPUs unterstützt, wirst du Funktionen doppelt implementieren müssen, wenn du möchtest, dass es gescheit auf beiden Architekturen läuft. Evtl. entwickelt es sich dahin, dass man die Programme zuerst komplett für die CPU entwickelt (weil es einfacher ist und man so schon mal die Funktionalität prüfen kann) und man sich dann in einem zweiten Durchgang die Performance-kritischen Funktionen heraussucht und für diese dann GPU-gestützte Varianten einbaut.
Zuletzt bearbeitet:
boidsen
Grand Admiral Special
@1: Bringt so gut wie garnix. weil die Caches eigentlich nur Strom verbrauchen, wenn sie auch genutzt werden und außerdem durch ihre Nutzung, je nach Programmcode, auch durchaus Strom in den Prozessorkernen, dem IMC und dem RAM gespart wird.
@2: Macht doch (fast) jeder AMD-Prozessor seit dem Sockel 754 schon von Haus aus, wenn man das nicht im Bios vom Board abstellt bzw. das Bios nicht vom Hersteller vermurkst wurde - Stchworte "Cool'n Quiet" und "C1E"...
@3: Das kann kein Prozessortreiber - das muss das Betriebssystem machen und zusätzlich auch noch das betreffende Programm unterstützen.
@4: Auch hier muss die Unterstützung durch die verwendete Software erfolgen - und das tut sie ja schon bei einer wachsenden Anzahl von Anwendungen...
@2: Macht doch (fast) jeder AMD-Prozessor seit dem Sockel 754 schon von Haus aus, wenn man das nicht im Bios vom Board abstellt bzw. das Bios nicht vom Hersteller vermurkst wurde - Stchworte "Cool'n Quiet" und "C1E"...
@3: Das kann kein Prozessortreiber - das muss das Betriebssystem machen und zusätzlich auch noch das betreffende Programm unterstützen.
@4: Auch hier muss die Unterstützung durch die verwendete Software erfolgen - und das tut sie ja schon bei einer wachsenden Anzahl von Anwendungen...
Hallo,
hast ja ein paar nette Ideen.
Die Frage ist nur, was für ein Aufwand ist dafür zu betreiben und was bringt es letztendlich?
Ich bin sicher, dass die Ingenieure bei AMD und INTEL alles mögliche in Betracht ziehen und beurteilen.
Man sieht es ja am Turbo: Intel vertraut auf Thermo-Diode, AMD ermittelt die jeweilige Auslastung und fährt darauf hin hoch.
Man merkt aber auch, wie lange es dauert bis sich neue Ideen in einem Design verwirklichen.
zu 3): soweit ich weiss, ist das Sache des Betriebssystems. Bei Linux kannste dir einen eigenen Kernel generieren, der ein entsprechendes sceduling Verhalten hat.
zu 4): um die GPU zu nutzen, muss dafür entweder der GPU Code mit im Programm vorhanden sein oder ein API wie Direct-Compute oder Open-CL oder Cuda wird genutzt. Diese Libraries entscheiden dann, was auf GPU und was auf CPU ausgeführt wird.
Flash, Webbrowser Codecs nutzen z.T. ja schon die Fähigkeiten der GPUs.
Einzige Möglichkeit ist halt, eine entsprechende API beim Programmieren zu verwenden.
Dann ist es dem Programm egal, wo die entsprechenden Funktionen ausgeführt werde, auf CPU oder GPU.
Tröste dich, ich hatte auch schon öfters Ideen und dachte: Warum machen die dieses und jenes nicht. War aber schon oft erstaunt, dass ich dann etwas später diese Ideen verwirklicht sah. Reiner Zufall bzw. die Zeit war einfach reif dafür.
Warten wir mal ab, was BD und Llano für Poweroptimierungen drin hat. Beim Ontario hab ich es jetzt nicht so verfolgt.
Hab wohl zulange zum tippen gebraucht
Kann Limit64 nur zustimmen.
hast ja ein paar nette Ideen.
Die Frage ist nur, was für ein Aufwand ist dafür zu betreiben und was bringt es letztendlich?
Ich bin sicher, dass die Ingenieure bei AMD und INTEL alles mögliche in Betracht ziehen und beurteilen.
Man sieht es ja am Turbo: Intel vertraut auf Thermo-Diode, AMD ermittelt die jeweilige Auslastung und fährt darauf hin hoch.
Man merkt aber auch, wie lange es dauert bis sich neue Ideen in einem Design verwirklichen.
zu 3): soweit ich weiss, ist das Sache des Betriebssystems. Bei Linux kannste dir einen eigenen Kernel generieren, der ein entsprechendes sceduling Verhalten hat.
zu 4): um die GPU zu nutzen, muss dafür entweder der GPU Code mit im Programm vorhanden sein oder ein API wie Direct-Compute oder Open-CL oder Cuda wird genutzt. Diese Libraries entscheiden dann, was auf GPU und was auf CPU ausgeführt wird.
Flash, Webbrowser Codecs nutzen z.T. ja schon die Fähigkeiten der GPUs.
Dazu müsste das Programm analysiert werden und entsprechend neu codiert werden. Ziemlicher Aufwand und kaum machbar. Ich hab ja schon bei ein paar tausend Zeilen C-Code Probleme die eigentliche Funktionalität zu erkennen und zu optimieren ( OK, es gibt auch sauberen Code bei dem ist es einfach).
Einzige Möglichkeit ist halt, eine entsprechende API beim Programmieren zu verwenden.
Dann ist es dem Programm egal, wo die entsprechenden Funktionen ausgeführt werde, auf CPU oder GPU.
Tröste dich, ich hatte auch schon öfters Ideen und dachte: Warum machen die dieses und jenes nicht. War aber schon oft erstaunt, dass ich dann etwas später diese Ideen verwirklicht sah. Reiner Zufall bzw. die Zeit war einfach reif dafür.
Warten wir mal ab, was BD und Llano für Poweroptimierungen drin hat. Beim Ontario hab ich es jetzt nicht so verfolgt.
Hab wohl zulange zum tippen gebraucht
Kann Limit64 nur zustimmen.
Zuletzt bearbeitet:
boidsen
Grand Admiral Special
Ich verwechsle es nicht, sondern setze es für den o.a. Fall gleich, weil es hier den gleichen Effekt erzielt - Taktabsenkung bei gleichzeitiger Reduzierung der Versorgungsspannnung der CPU.
2 gibt es schon das Problem dabei ist , das Win 7 zum Beispiel im Normalfall bei einer Auslastung der CPU von ca. 50% den Takt auf die nächsthöhere Stufe schaltet, was im allgemeinen eine zu tiefe limite ist, da mit 800MHz die 50% Limite mit Youtube zum Teil schon erreicht wird. 80% währe optimaler.
Ich weiss, Jedoch ist es im Normalfall für Notebooks, die bessere Einstellung und sollte zumindest da Standart sein. Und ich hasse zusatztools für Sachen mit schlechter Standarteinstellungen analog zu (Flashblock, damit die Flash Werbung nicht heruntergeladen wird, wenn kein Flash installier ist ).
Zum 1. Das ist sicher in der Mache und wird auch kommen, da IMO bei schrumpfenden strukturen die Leckströme der Transistoren zunehmend problematisch werden und sich daher grade bei caches, die aus sehr vielen transitoren bestehen durchaus was einsparen lässt.
Die richtige Metrik auszutüfteln ist ein spezielles Problem, alla "ab wann lohnt es sich mehr Cache freizuschalten und damit ggf. Speicherzugriffe zu sparen"...
2. Throtteling spart kaum was. Eine bei 800Mhz idelnde CPU spart nur minimalst wenn man weiter runter geht... das lohnt den Aufwand kaum. Hier wird dann wichtiger dass man z.B. nicht genutzte Kerne stromlos schaltet etc. also verweis auf 1.
3. Hier wirds kompliziert. Ein einzelnes Single-Threaded Programm, kann nicht auf mehrere kerne aufgeteilt werden. Auch nicht vom Betriebssystem, da der Programmcode von zwischenergebnissen abhängt die nur in den Registern und caches des Kernes vorliegen der sie berechnet hat... bzw. ständig weiterrechnen lässt und die ergebnisse einer Berechnung für die nächste gebraucht werden.
Multithreading muss vom Programmierer explizit vorgesehen werden! - Nur dieser hat den nötigen Überblick über das Programm um zu wissen welche Teile voneinander unabhängig laufen können und welche nicht...
Das OS hat wiederum andere Schwierigkeiten bei der Entscheidung welche Threads es auf wechen Kern packt... angenommen ich habe 4 Threads... packe ich die auf eine CPU, die im 2. niedrigsten P-State lässt und die anderen abschaltet, oder wäre es energetisch effizienter 2 Kerne mit niedrigstem P-state laufen zu lassen?
Also der "richtige" scheduling--Algorithmus ist alles andere als trivial, und leider auch abhängig von der Hardware und Gerätetyp bzw. was ist wichtiger, kurze Reaktionszeit oder minimaler stromverbrauch? (Server oder Notebook?)
4. Kannst du auf diese Weise erstmal komplett knicken.
GPU-Programmierung unterscheidet sich fundamental von CPUs... nicht wegend er Programmiersprache sondern weil GPUs schleifen z.b. nicht wirklich effizient ausführen, CPUs aber schon... Während eine CPU mehr ode rminder Wahllos Speicher adressieren kann und damit herumwerkeln, mehrstufige cachehierarchien und Sprungvorhersage zur Verfügung hat, schöpfen GPUs ihre Leistung daraus dass sie sich diesen Transistorenaufwand sparen und stattdessen mehr recheneinenheiten verbauen, die allerdings die Daten am besten in Streaming-Manier haben wollen, konstanter Datenfluss und konstante Ausgabe...
Also eine CPU besitzt zwar weniger Rechen-Ressourcen, dafür geht sie effizient mit ihnen um und verschwendet einen beträchtlichen Teil ihrer Komplexität darauf die Recheneinheiten ausgelastet zu halten... während eine GPU vergleichsweise "dumm" ist, im Sinne von weniger Verwaltungsaufwand und Brimborium, dafür aber eben mehr recheneinheiten zur Verfügung hat...
Im klartext heißt das, GPUs sind nur schnell wenn man ihnen die Daten "vorgekaut" anliefert... wie am Fließband. - Ist das nicht der Fall, sind sie nicht wirklich leistungsstärker als moderne CPUs.
Dann gibt es noch Einschränkungen im Speicherzugriff... GPUs können auf ihren eigenen Speicher effizienter zugreifen als auf System-RAM (der muss ja erst über PCI-Express angesprochen werden...)
usw.
Also "Mal eben" die revolution auszurufen ist nicht...
Die richtige Metrik auszutüfteln ist ein spezielles Problem, alla "ab wann lohnt es sich mehr Cache freizuschalten und damit ggf. Speicherzugriffe zu sparen"...
2. Throtteling spart kaum was. Eine bei 800Mhz idelnde CPU spart nur minimalst wenn man weiter runter geht... das lohnt den Aufwand kaum. Hier wird dann wichtiger dass man z.B. nicht genutzte Kerne stromlos schaltet etc. also verweis auf 1.
3. Hier wirds kompliziert. Ein einzelnes Single-Threaded Programm, kann nicht auf mehrere kerne aufgeteilt werden. Auch nicht vom Betriebssystem, da der Programmcode von zwischenergebnissen abhängt die nur in den Registern und caches des Kernes vorliegen der sie berechnet hat... bzw. ständig weiterrechnen lässt und die ergebnisse einer Berechnung für die nächste gebraucht werden.
Multithreading muss vom Programmierer explizit vorgesehen werden! - Nur dieser hat den nötigen Überblick über das Programm um zu wissen welche Teile voneinander unabhängig laufen können und welche nicht...
Das OS hat wiederum andere Schwierigkeiten bei der Entscheidung welche Threads es auf wechen Kern packt... angenommen ich habe 4 Threads... packe ich die auf eine CPU, die im 2. niedrigsten P-State lässt und die anderen abschaltet, oder wäre es energetisch effizienter 2 Kerne mit niedrigstem P-state laufen zu lassen?
Also der "richtige" scheduling--Algorithmus ist alles andere als trivial, und leider auch abhängig von der Hardware und Gerätetyp bzw. was ist wichtiger, kurze Reaktionszeit oder minimaler stromverbrauch? (Server oder Notebook?)
4. Kannst du auf diese Weise erstmal komplett knicken.
GPU-Programmierung unterscheidet sich fundamental von CPUs... nicht wegend er Programmiersprache sondern weil GPUs schleifen z.b. nicht wirklich effizient ausführen, CPUs aber schon... Während eine CPU mehr ode rminder Wahllos Speicher adressieren kann und damit herumwerkeln, mehrstufige cachehierarchien und Sprungvorhersage zur Verfügung hat, schöpfen GPUs ihre Leistung daraus dass sie sich diesen Transistorenaufwand sparen und stattdessen mehr recheneinenheiten verbauen, die allerdings die Daten am besten in Streaming-Manier haben wollen, konstanter Datenfluss und konstante Ausgabe...
Also eine CPU besitzt zwar weniger Rechen-Ressourcen, dafür geht sie effizient mit ihnen um und verschwendet einen beträchtlichen Teil ihrer Komplexität darauf die Recheneinheiten ausgelastet zu halten... während eine GPU vergleichsweise "dumm" ist, im Sinne von weniger Verwaltungsaufwand und Brimborium, dafür aber eben mehr recheneinheiten zur Verfügung hat...
Im klartext heißt das, GPUs sind nur schnell wenn man ihnen die Daten "vorgekaut" anliefert... wie am Fließband. - Ist das nicht der Fall, sind sie nicht wirklich leistungsstärker als moderne CPUs.
Dann gibt es noch Einschränkungen im Speicherzugriff... GPUs können auf ihren eigenen Speicher effizienter zugreifen als auf System-RAM (der muss ja erst über PCI-Express angesprochen werden...)
usw.
Also "Mal eben" die revolution auszurufen ist nicht...
Dresdenboy
Redaktion
☆☆☆☆☆☆
Auch noch etwas Senf von mir, deckt sich bestimmt mit einigen anderen Aussagen:
"1) Cache dynamisch deaktvieren"
- wird kommen
- lohnt sich -> Leakage bei nicht power gated Schaltungen in 32nm schon ~30% (siehe Llano ISSCC 2010), kann mit anderen Transistoren u. SRAMS (8T) reduziert werden, aber dennoch vorhanden
- Patente dafür existieren
- für BD-L3 recht wahrscheinlich, BD-L2 u. BC-L2 haben das möglicherweise auch
"2) Throtteling zum Energiesparen nutzten"
- wird ja schon gemacht, aber nicht temperaturabhängig, sondern lastabhängig
- wird verbessert, dank genauerer Erfassung des Energieverbrauchs
- Gegenkonzept: Race-to-sleep: da System u. Komponenten auch Strom benötigen, ist es durch kurze, performante Phasen (wenn Auslastung hoch) mit Turbo möglich, schneller zu den Sparphasen zu gelangen u. möglicherweise Komponenten dadurch abschalten zu können (Aktivitätszeiten verkürzt)
"3) Per Prozessortreiber Workloads besser verteilen?"
- wird schon in diversen OS-Schedulern gemacht
- explizite Kopplung mit Power Management ist noch nicht so gegeben, aber passiert automatisch
"4) Fusion 4all"
- klingt nach JIT
- Übersetzung von x86-Code in einen nativen GPU-Befehlssatz wurde auch schon angedacht, aber nur wegen Kompatibilität
- wegen Performanzsteigerungen kaum sinnvoll, da hinter parallelem GPU-Code ein ganz anderes Konzept steckt als hinter x86-Code
"1) Cache dynamisch deaktvieren"
- wird kommen
- lohnt sich -> Leakage bei nicht power gated Schaltungen in 32nm schon ~30% (siehe Llano ISSCC 2010), kann mit anderen Transistoren u. SRAMS (8T) reduziert werden, aber dennoch vorhanden
- Patente dafür existieren
- für BD-L3 recht wahrscheinlich, BD-L2 u. BC-L2 haben das möglicherweise auch
"2) Throtteling zum Energiesparen nutzten"
- wird ja schon gemacht, aber nicht temperaturabhängig, sondern lastabhängig
- wird verbessert, dank genauerer Erfassung des Energieverbrauchs
- Gegenkonzept: Race-to-sleep: da System u. Komponenten auch Strom benötigen, ist es durch kurze, performante Phasen (wenn Auslastung hoch) mit Turbo möglich, schneller zu den Sparphasen zu gelangen u. möglicherweise Komponenten dadurch abschalten zu können (Aktivitätszeiten verkürzt)
"3) Per Prozessortreiber Workloads besser verteilen?"
- wird schon in diversen OS-Schedulern gemacht
- explizite Kopplung mit Power Management ist noch nicht so gegeben, aber passiert automatisch
"4) Fusion 4all"
- klingt nach JIT
- Übersetzung von x86-Code in einen nativen GPU-Befehlssatz wurde auch schon angedacht, aber nur wegen Kompatibilität
- wegen Performanzsteigerungen kaum sinnvoll, da hinter parallelem GPU-Code ein ganz anderes Konzept steckt als hinter x86-Code
HelixUltra
Fleet Captain Special
- Mitglied seit
- 21.11.2008
- Beiträge
- 254
- Renomée
- 9
Wow, erstmal danke für euer starkes Feedback
Das die ersten beiden Ideen so oder so ähnlich schon umgesetzt wurden und werden freut mich natürlich, hätte nicht gedacht das Throtteling tatsächlich schon in ähnlicher Form genutzt wird.
Zu 3) und 4). Hier muss ich zugeben, zu wenig nachgedacht zu haben, die Ideen sind Abends im Halbschalf entstanden.
Das mit dem Scheduler ist natürlich etwas, was ich vollkommen außer acht gelassen hatte.
@Limit 64
Hat den der eigene Scheduler seinen Sinn erfüllt oder war das mehr eine Machbarkeitsstudie? Ich erinner mich an einen Artikel auf Tecchanel oder ZDNet, wo von einem "Experten" betont wurde, das aktuelle Software bei Handoptimierung bis an die Grenzen zwischen 5 und 10 mal schneller sein könnte. In wie fern das so richtig ist sei mal dahingestellt, aber die Lücke die zwischen Leistung in Hardware und Leistung die hinten raus kommt klafft schon mächtig auseinander.
Gameboy Advance, 3MHz = Pokemon macht süchtig
AMD Athlon X2 = Crysis läuft annehmbar.
Ok, scheiß Vergleich, aber ich denke mal ihr wisst auf was ich abziele
Das mit 4) ist aus der Idee entstanden, neben Flash und Videos auch andere Sachen auf der Grafikkarte zu beschleunigen, OpenCL und die Richtung.
@ Dresdenboy
JIT Kenn ich von meinem Androiden, aber wirklich verstehen tue ich das Prinzip nicht. Werde mich mal einlesen.
Achso, was ich noch fragen wollte: Wie sieht das mit Race-to-sleep aus?
Leider werden nur bei ganz ganz wenigen Chips der Stromverbrauch pro Takt oder ähnlich angegeben. Als Laie würde ich fast behaupten, das es aufs gleiche rauskommt, 2 langsame Kerne arbeiten zu lassen, oder einen schnellen der dafür mehr Strom frisst.
Wie sieht das von technischer Seite aus, also mit tiefgreifenden Kenntnissen die ich nicht habe?
Das die ersten beiden Ideen so oder so ähnlich schon umgesetzt wurden und werden freut mich natürlich, hätte nicht gedacht das Throtteling tatsächlich schon in ähnlicher Form genutzt wird.
Zu 3) und 4). Hier muss ich zugeben, zu wenig nachgedacht zu haben, die Ideen sind Abends im Halbschalf entstanden.
Das mit dem Scheduler ist natürlich etwas, was ich vollkommen außer acht gelassen hatte.
@Limit 64
Hat den der eigene Scheduler seinen Sinn erfüllt oder war das mehr eine Machbarkeitsstudie? Ich erinner mich an einen Artikel auf Tecchanel oder ZDNet, wo von einem "Experten" betont wurde, das aktuelle Software bei Handoptimierung bis an die Grenzen zwischen 5 und 10 mal schneller sein könnte. In wie fern das so richtig ist sei mal dahingestellt, aber die Lücke die zwischen Leistung in Hardware und Leistung die hinten raus kommt klafft schon mächtig auseinander.
Gameboy Advance, 3MHz = Pokemon macht süchtig
AMD Athlon X2 = Crysis läuft annehmbar.
Ok, scheiß Vergleich, aber ich denke mal ihr wisst auf was ich abziele
Das mit 4) ist aus der Idee entstanden, neben Flash und Videos auch andere Sachen auf der Grafikkarte zu beschleunigen, OpenCL und die Richtung.
@ Dresdenboy
JIT Kenn ich von meinem Androiden, aber wirklich verstehen tue ich das Prinzip nicht. Werde mich mal einlesen.
Achso, was ich noch fragen wollte: Wie sieht das mit Race-to-sleep aus?
Leider werden nur bei ganz ganz wenigen Chips der Stromverbrauch pro Takt oder ähnlich angegeben. Als Laie würde ich fast behaupten, das es aufs gleiche rauskommt, 2 langsame Kerne arbeiten zu lassen, oder einen schnellen der dafür mehr Strom frisst.
Wie sieht das von technischer Seite aus, also mit tiefgreifenden Kenntnissen die ich nicht habe?
Kenn ich, hab ich auch die dollsten Einfälle.
OpenCL macht ja genau das. Man programmiert die Aufgae mit der OpenCL API und der Treiber entscheidet, ob es auf der Grafikkarte ausgeführt wird oder ob die CPU die Aufgabe beareitet.
JIT = Just In Time
Während der Code eingelesen wird, wird er direkt passend umgewandelt bzw. compiliert.
Z.B. Java Code, .Net glaub ich auch.
Wenn ichs richtig zusammenbekomme, spielen 2 Komponenten die wesentliche Rolle:
1) der Leckstrom. Ist immer vorhanden. Die Transistoren sperren nicht zu 100%, die Leitungen liegen so dicht zusammen, dass dazwischen ein geringer Strom fließen kann etc. Also auch wenn der Chip nichts tut, fließt trotzdem ein Strom.
2) bei jedem Schaltvorgang eines Transistors fließt Strom. Da viele Transistoren vorhanden sind und nicht bei jedem Takt alle schalten, kann man den Verbrauch/Takt gar nicht angeben.
Du meinst aber sicher noch was anderes: Du wüßtest gerne, was z.B. ein Phenom II 955 bei 3GHz, 2,5GHz, 2GHz etc. braucht.
Wüsste ich auch gerne.
Dann bräuchte ich nicht zu überlegen, ob ich mir einen E-Type kaufe oder einen normalen kaufe und dann runtertakte.
Nun ja, es war doch eher eine Machbarkeitsstudie. Die Testergebnisse ließen zwar Vermutungen zu, dass es was bringt, aber es lag alles noch im Rahmen der Messungenauigkeit. Die Ergebnisse hätten wahrscheinlich deutlich besser sein können, aber aus verschiedenen Gründen wurde es nicht so toll. Was ich damit aber eigentlich sagen wollte war ja, dass es in dem Bereich jede Menge Forschung gibt (Hier am Kit gibt es einen extra Lehrstuhl dafür).
Den Artikel kenne ich auch, aber die die Aussage die da gemacht wurde, muss man differenzierter betrachten. Einmal erzählt er, dass durch Handoptimierung manche Programme bis zum Faktor 10 beschleunigt werden können, was durchaus richtig ist, z.B. x264. Aber das trifft bei weitem nicht auf alle Programme zu, um genau zu sein nur auf eine Minderheit. x264 ist ein extrem rechenlastiges Programm das dazu noch datenflussgetrieben ist, so dass man die SSE/MMX Einheit gut auslasten kann, wenn man den Code entsprechend vektorisiert.
Der zweite Punkt, den er Anspricht sind heterogene anwendungsspezifische Multicore CPUs, d.h. man hat eine CPU die unterschiedliche Kerne besitzt, die für bestimmte Anwendungsgebiete optimiert wurde (Stichwort: ASIP). Das Prinzip ist das gleiche, wegen dem man mittlerweile eine CPU und eine GPU hat, für Grafikberechnungen ist eine GPU einfach deutlich besser geeignet als eine CPU. Entsprechend könnte man spezialisierte Cores für Physik, Kryptographie, Bild-/Videobearbeitung, KIs oder sonst etwas zusammen auf einem Chip zusammenbauen. Man hätte also für jeden Anwendungszweck einen Core, der nicht nur schneller ist als eine General Purpose CPU, sondern dabei auch noch stromsparender.
JIT-Compiler kommen häufig dann zum Einsatz, wenn Programmcode auf unterschiedlichen Architekturen laufen soll ohne das man extra irgendwelche Anpassungen vornehmen muss. Der Programmcode wird für eine virtuelle Maschine (mit eigenem Befehlssatz, Registern usw.) compiliert. Der JIT-Compiler transformiert den Code dann zur Laufzeit so, dass er auf der realen CPU ausführbar ist. Die Alternative wäre es die virtuelle CPU zu emulieren, was z.B. bei Java anfangs auch so gemacht wurde. Das Prinzip kann man mit gewissen Einschränkungen auch für GPUs verwenden, was aber wie schon gesagt performancemäßig nicht viel bringt, da GPUs eine komplett andere Architektur besitzen.
Es gibt für diese Sachen keine allgemeingültigen Lösungen. Es ist ein Optimierungsproblem mit sehr vielen Variablen.
Race-to-sleep bedeutet wohl, dass man z.B. eine CPU hochtaktet, damit sie schneller fertig wird und man dann z.B. den ganzen Rechner abschalten kann. Durch das Hochtakten (und dafür notwendig höhere Spannung) steigt der Stromverbrauch im Vergleich zum Performancegewinn überproportional an, so dass es für die CPU alleine genommen insgesamt mehr Energie kostet. Da man aber anschließend den ganzen Rechner ausschalten kann (und man damit auch den Verbrauch aller anderen Komponenten einspart) kann es sich trotzdem lohnen.
Zuletzt bearbeitet:
Zum letzten Punkt kommt es auch auf die Bauart der CPUs an.
Wenn eine CPU große Kerne hat, die als gesamt-Kern powergaten können, würde ich lieber einen davon auf höherem Takt laufen lassen, und die anderen komplett stromlos machen, als die doppelte Anzahl an Transistoren "durchzufüttern", wenn auch mit geringeren Takten.
Ist der Kern aber ohnehin nicht vollständig stromlos schaltbar, kommt es jetzt drauf an wie viel mehr Strom er auf dem angepeilten P-State zieht wie im IDLE.
Das sind aber konkrete Überlegungen die man nicht allgemein treffen kann. Dazu spielen Architektur, fertigungsprozess usw. eine zu große Rolle.
z.B. kann eine in 32nm ULK gefertigte CPU da ganz andere Eigenschaften haben als 32nm bulk...
Einfach deswegen weil bei ersterer die Leckströme nicht so groß sind.
Aber genau hier liegt der Hund begraben, was uns als Laien "aufs gleiche rauskommt" ist für experten mit durchblick sehr schwer festzulegen...
Wenn eine CPU große Kerne hat, die als gesamt-Kern powergaten können, würde ich lieber einen davon auf höherem Takt laufen lassen, und die anderen komplett stromlos machen, als die doppelte Anzahl an Transistoren "durchzufüttern", wenn auch mit geringeren Takten.
Ist der Kern aber ohnehin nicht vollständig stromlos schaltbar, kommt es jetzt drauf an wie viel mehr Strom er auf dem angepeilten P-State zieht wie im IDLE.
Das sind aber konkrete Überlegungen die man nicht allgemein treffen kann. Dazu spielen Architektur, fertigungsprozess usw. eine zu große Rolle.
z.B. kann eine in 32nm ULK gefertigte CPU da ganz andere Eigenschaften haben als 32nm bulk...
Einfach deswegen weil bei ersterer die Leckströme nicht so groß sind.
Aber genau hier liegt der Hund begraben, was uns als Laien "aufs gleiche rauskommt" ist für experten mit durchblick sehr schwer festzulegen...
Ähnliche Themen
