CPU-Verbrauch: Der Effizienz-Index für Prozessoren

[Bl4ckR4v3n]

Auch wenn du es noch öfter schreibst, ich habe sehr wohl verstanden was du ständig wiederholst. Was du scheinbar nicht daraus zu lesen vermagst ist, dass ich eben jene Methodik ablehne.
Das ist wie mit den früheren Verbrauchsangaben der Kfz-Hersteller. Stansardisierte Umgebung, mit vermeintlich repräsentativen Lasten aus denen man Fantasiewerte bekommt. Mit der Realität, welche bei fast jedem anders ausschaut, hat das wenig zu tun. KANN Es durchaus, aber tut es oft nicht.
Wir können es ja noch einmal aufgreifen, wenn die Werte vorliegen. Dann gucken wir zusammen was man daraus ableiten kann und schauen wie wertvoll die erhobenen Daten tatsächlich sind.

Du beweist gerade meinen Punkt. Ein Gesamtsystemtest ist sehr vom Nutzer abhängig und ich kann aus so einem Test nichts ziehen. Vor allem dann nicht wenn die Testmethodik weder dazu gedacht ist noch die notwendigen Lastbereiche zeigt.
Ich könnte dir bei vorgabe des Fahrprofils nur mit Kenntnis des Motorkennfeldes (Getriebe wäre mir bspw. egal) bereits einen Wertebereich (ca. +-1l/h) vorhersagen, indem der Verbrauch liegt. Wenn du mir dann noch Getriebe und Fzg. Daten gibst kann man das auf den < 0,1 Liter genau vorhersagen.
Wir können aber gerne beim neuen Test prüfen was für aussagen getroffen werden können.

 

[RyzA]

Die RISC/CISC denke ist seit dem Pentium Pro schon erledigt. Seitdem sind x86 CPUs nämlich auch RISC Kerne mit Frontend statt "echten" CISC CPUs. Deswegen ist Effizienz am Befehlssatz fest zu machen in der Regel auch ein Irrweg.

Achso ok. Das wusste ich nicht.

 

[PCGH_Torsten]

Die RISC/CISC denke ist seit dem Pentium Pro schon erledigt. Seitdem sind x86 CPUs nämlich auch RISC Kerne mit Frontend statt "echten" CISC CPUs. Deswegen ist Effizienz am Befehlssatz fest zu machen in der Regel auch ein Irrweg.
AVX ist übrigens irre Effizient. Da kommt nämlich nicht nur viel Hitze sondern auch viel Rechenleistung bei rum.

Besagtes Frontend frisst unter anderem deswegen sehr viel Energie und Decoding-Vorgänge zu vermeiden ist seit langem ein Optimierungspunkt bei x86-Prozessoren. Allerdings hängt die Gesamtbilanz stark von der Anwendung ab, denn mit einem RISC-Befehlssatz muss die Zerlegung in simpelste Rechenoperationen halt schon im Progammcode erfolgen. Je einfacher die Aufgabe und desto geringer die Leistungsanforderungen, desto weniger Nutzen (bei vollen Kosten) bringt ein CISC-zu-RISC-Decoder; je komplexer die Aufgabe und je schlechter die Software-Optimerung, desto eher hat RISC ein Problem. In Low-End und lange Zeit auch mobile-Anwendungen führt(e) deswegen kein Weg an RISC vorbei; umgekehrt hat Itanic bewiesen, dass man sich nicht auf Programmierer verlassen sollte.

 

[PCGH_Dave]

Der Artikel wurde komplett überarbeitet und ich freue mich auf Feedback

 

[Elthy]

Ist der i7 3770k ernsthaft bei der Anwendungseffizienz auf dem 3. Platz? Er zwar die niedrigste Leistungsaufnahme, aber die Leistung dürfte auch am hinteren Ende liegen. Der 5950X verbraucht in Anwendungen ungefähr das Doppelte, dürfte aber dank 4mal mehr Kernen und deutlich besserer IPC signifikant mehr als die doppelte Leisung haben, oder? Dann dürfte aber nicht der Effizenzscore fast gleich sein.

 

[ToZo1]

Die RISC/CISC denke ist seit dem Pentium Pro schon erledigt. Seitdem sind x86 CPUs nämlich auch RISC Kerne mit Frontend statt "echten" CISC CPUs. Deswegen ist Effizienz am Befehlssatz fest zu machen in der Regel auch ein Irrweg.
AVX ist übrigens irre Effizient. Da kommt nämlich nicht nur viel Hitze sondern auch viel Rechenleistung bei rum.

Ich kann mich an diese damals schon eher sinnfreie Diskussion CISCvRISC vor 20 Jahren an der Uni erinnern. Wo aus entsprechenden Kreisen regelmäßig die heiligen und eleganten Motorola PowerProzessoren (RISC) in jedem Amiga/Mac der lahmen und quasi schon prinzipiell toten x86-Technologie ja so mörderisch überlegen war. Heute ist Amiga tot und Her Steveness kündigte ein paar Jahre später blasphemisch neue Macs mit natürlich 3x schnelleren x86er IntelCPUs als Nachfolger der G5-Macs an. Wenn man älter wird, lächelt man irgendwann über solche heiligen und so sinnlosen Dispute nur noch milde...

Besagtes Frontend frisst unter anderem deswegen sehr viel Energie und Decoding-Vorgänge zu vermeiden ist seit langem ein Optimierungspunkt bei x86-Prozessoren. Allerdings hängt die Gesamtbilanz stark von der Anwendung ab, denn mit einem RISC-Befehlssatz muss die Zerlegung in simpelste Rechenoperationen halt schon im Progammcode erfolgen. Je einfacher die Aufgabe und desto geringer die Leistungsanforderungen, desto weniger Nutzen (bei vollen Kosten) bringt ein CISC-zu-RISC-Decoder; je komplexer die Aufgabe und je schlechter die Software-Optimerung, desto eher hat RISC ein Problem. In Low-End und lange Zeit auch mobile-Anwendungen führt(e) deswegen kein Weg an RISC vorbei;

Jepp, so isses.

umgekehrt hat Itanic bewiesen, dass man sich nicht auf Programmierer verlassen sollte.

Oder auch AMDs P4-Heatburst-Flop namens Bulldozer. Diese Architektur war trotz x86 genauso softwareoptimierungsbedürftig oder sonst lahm und heiß wie Hulle.

 

[PCGH_Dave]

Dann dürfte aber nicht der Effizenzscore fast gleich sein.

Da hast du vollkommen recht. Beim Checken der Zahlen ist mir ein Fehler in der Formel bei der 3770K aufgefallen. Ich hab das direkt angepasst, danke fürs Melden Die Änderungen gehen in ein paar Minuten online.

 

[TheGermanEngineer]

Schade, dass zwar 3. und 4. Generation dabei sind, aber nichts aus 6. oder 7. Generation.
Irgendwas scheint an den Diagrammen aber auch noch nicht zu stimmen, sie sind nicht immer richtig sortiert. Man muss teils noch mal manuell auf den Sortierwert klicken (auch um aufsteigend/absteigend zu wechseln), damit die Reihenfolgen passt.

 

[t670i]

Tolle Übersicht.
Eigenlicht weiß man es ja, aber ist immer wieder erstaunlich zu sehen, wie schlecht / ineffizient die 11. Intel Generation war.
Mit Alderlake geht es aber zum Glück wieder in die richtige Richtung.

 

[PCGH_Dave]

Ein 7700K findet bald seinen Weg in den CPU-Index
Ein 6700K steht mir noch immer nicht zur Verfügung, leider. Ein 7600K ist zwar vorhanden, aber fest in einem Testsystem verbaut. Den kann ich aber theoretisch aus dem 7700K basteln.

 

[OldboyX]

Also die effizienteste Spiele CPU (FPS pro Watt) ist ein 10400F? Deutlich vor 11400 und 12400? Das erschließt sich mir nicht. Gabs da nur Rückschritte oder wie?

 

[TheGermanEngineer]

Ein 7700K findet bald seinen Weg in den CPU-Index
Ein 6700K steht mir noch immer nicht zur Verfügung, leider.

Danke, einer der beiden würde ja reichen, sind ja ähnlich genug.

 

[PCGH_Dave]

Also die effizienteste Spiele CPU (FPS pro Watt) ist ein 10400F? Deutlich vor 11400 und 12400? Das erschließt sich mir nicht. Gabs da nur Rückschritte oder wie?

Rocket Lake war in jeder Hinsicht ein Rückschritt in Sachen Effizienz und ein 12400 kommt nicht an die goldenen Zeiten des 10400F heran, korrekt. Das heißt ja nicht, dass sie langsamer wären, aber das Fps/Watt-Verhältnis des 10400F erreichen die Nachfolger nicht. Vielleicht wird es ja was mit dem 13400(F), aber ich glaube vor Meteor Lake nicht mehr da dran.

 

[Bärenmarke]

Der Artikel wurde komplett überarbeitet und ich freue mich auf Feedback

Ein herausragender Artikel wie ich finde! Dafür hast du dir ein großes Lob verdient! Da werde ich mir dann auch erstmal die neuste pcgh als Anerkennung kaufen gehen Auch wenn man dies aufgrund der Mod Leistung, die gegensätzlich zu deiner Leistung steht nicht tun sollte.

Vor allem die Generationenübergreifende Einordnung finde ich super, da sieht man deutlich wie sich die Effizienz verbessert hat oder halt nicht In Anbetracht der Tatsache, dass von einigen intels neue Architektur mit dem Big-Little-Prinzip als sooooo super effizient gefeiert wird, ist das ja fürmlich ein Schlag ins Gesicht, da dies offenkundig nicht der Fall ist

 

[Govego]

Warum frisst der 12400 im Idle so viel? Der liegt beim Wattverbrauch an zweiter Stelle.

Fallen Anwendungen wie Internet, Office etc.eigentlich, wegen ihrer kaum vorhandenen Last, auch unter Idle? Die meisten PC-Besitzer nutzen ihn nämlich genau dafür.

 

[PCGH_Dave]

Ein herausragender Artikel wie ich finde! Dafür hast du dir ein großes Lob verdient!

Danke.

Auch wenn man dies aufgrund der Mod Leistung, die gegensätzlich zu deiner Leistung steht nicht tun sollte.

Das ist lange her und kein Maßstab mehr.

In Anbetracht der Tatsache, dass von einigen intels neue Architektur mit dem Big-Little-Prinzip als sooooo super effizient gefeiert wird, ist das ja fürmlich ein Schlag ins Gesicht, da dies offenkundig nicht der Fall ist

Intel selbst hat die Effizienz mit Rocket Lake verglichen. Kein Wunder, dass Alder Lake da Bestnoten erzielt

@Govego
Idle bedeutet wirlich "nichts tun". Es reicht schon den Browser zu öffnen oder ein Programm und die CPU springt mit dem Takt kurz nach oben und somit der Verbrauch. Ich messe den Wert auch erst nach dem Einpendeln, beim ersten Start des Analyse-Tools liegt der Idle-Verbrauch 10 bis 30 Prozent über den eigentlichen Werten.

 

[PCGH_Torsten]

Ich kann mich an diese damals schon eher sinnfreie Diskussion CISCvRISC vor 20 Jahren an der Uni erinnern. Wo aus entsprechenden Kreisen regelmäßig die heiligen und eleganten Motorola PowerProzessoren (RISC) in jedem Amiga/Mac der lahmen und quasi schon prinzipiell toten x86-Technologie ja so mörderisch überlegen war. Heute ist Amiga tot und Her Steveness kündigte ein paar Jahre später blasphemisch neue Macs mit natürlich 3x schnelleren x86er IntelCPUs als Nachfolger der G5-Macs an. Wenn man älter wird, lächelt man irgendwann über solche heiligen und so sinnlosen Dispute nur noch milde...


Jepp, so isses.

Oder auch AMDs P4-Heatburst-Flop namens Bulldozer. Diese Architektur war trotz x86 genauso softwareoptimierungsbedürftig oder sonst lahm und heiß wie Hulle.

Netburst und Bulldozer hatten in erster Linie ein anderes Problem: Klein und einfach aber dank hohem Takt trotzdem flott sollten sie sein. Geplant wurde das aber kurz vor/zur Jahrtausenwende, als hochtaktende CPUs ein paar 100 MHz und um die 30 W hatten. Als es dann bei 4-5 GHz 150 W und mehr werden wurden und auch noch Fertigungsproblemen oder Verzögerungen hinzukamen (Williamette, Prescott/Smithfield respektive Zambezi)...
Netburst hätte das durch eine Ummünzung der geringen Transistorzahl in niedrige Preise ausgleichen können, aber zum einen brauchte man riesige Caches, um Falschvorhersagen zu kompensieren, und zum anderen war es halt Intel. Bulldozer hat es mit mehr Kernen auf gleicher Fläche versucht, aber es gab kaum Multi-Core-Anwendungen. Von den Kernen her waren aber beide Architekturen recht konventionell für Entwickler. Netburst konnte seine Leistung gut entfalten, Bulldozer hätte es mit den später verfügbaren 8-Thread-Anwendungen auch gekonnt.

Nützt aber halt nichts, wenn die pro Watt gelieferte Leistung eher bescheiden ist.

 

[Bärenmarke]

Danke.

Sehr gerne Gute Arbeit soll ja auch schließlich honoriert werden.

Intel selbst hat die Effizienz mit Rocket Lake verglichen. Kein Wunder, dass Alder Lake da Bestnoten erzielt

Da kann man dann natürlich immer glänzen Aber ich finde das zeigt auch wieder sehr gut auf, wie die einzelnen Hersteller tricksen.
Und ich finde ihr geht da sehr neutral an die Sache heran, weil wenn man bei der Testmethodik die Schwachstelle eines Konzeptes herausgreift - wie es beispielsweise CapeXFrame machen - dann bekommt man ein ziemlich verschobenes Bild.
Um konkret zu werden hatten sie einen 5900X mit dem 11900K (der Zehnkerner intel war es aufjedenfall) verglichen, um die Effizienz der einzelnen CPU Kerne aufzuzeigen. Alleine, dass man nicht den gleichen Corecount verwendet finde ich für Vergleichszwecke schon sehr unseriös und zum anderen greift man gezielt die Schwachstelle des AMD Konzepts für den Vergleich auf, da ich bei zwei Chiplets deutlich mehr Energie für die Kommunikation innerhalb der CPU benötige.
Daher wäre ein sinnvoller Effizienztest nur bei 5800X + intel Gegenstück oder bei APUs sinnvoll gewesen. Weil letztendlich möchte man ja wissen wie effizient die einzelnen Kerne sind und nicht wie groß der Einfluss vom I/O Part etc. ist. Was für einen gesonderten Test mit Sicherheit auch spannend ist, wenn es darum geht die Vor- und Nachteile einer Architektur zu vergleichen.


Ansonsten müsste man hingehen und einmal für jedes Konzept den absoluten Worstcase und einmal den Bestcase abbilden, aber das finde ich auch nur bedingt zielführend.
Dazu würde mich mal deine Meinung brennend interessieren.

 

[Gelöschtes Mitglied 217606]

PCGH und Effizienzmessungen, das ist immer ein brisantes Thema.

In die Werte fließt die Effizienz der Spannungswandler auf dem Mainboard mit ein. Somit spiegelt der Wert genau das wider, was die CPU tatsächlich aus der Leitung zieht.

Ne @PCGH_Dave , du sagst es ja im ersten Satz, der Wärmeverlust an den VRMs hängt auch von der Effzienz der VRMs ab. EPS 12V spiegelt also nicht nur den Verbrauch der CPU wider. Je schlechter die Effizienz der VRMs, desto höher der Verbrauch. Nimmt man ein anderes Board, kann was anderes rauskommen.

Wenn ich mir die Werte des i9-11900K anschaue, dann lässt sich der hohe Verbrauch nur dadurch erklären, dass ihr beim Messen genau die Tau-Phase mitnehmt. Aber warum? Sind die 56 Sekunden Tau wirklich repräsentativ für den Verbrauch in Spielen? 56 Sekunden gegenüber Stunden, die ein Spiel auf dem System laufen kann?

Sorry, aber für mich ist das methodisch sehr schwach, was hier geboten wird.

Aber ich finde das zeigt auch wieder sehr gut auf, wie die einzelnen Hersteller tricksen.
Und ich finde ihr geht da sehr neutral an die Sache heran, weil wenn man bei der Testmethodik die Schwachstelle eines Konzeptes herausgreift - wie es beispielsweise CapeXFrame machen - dann bekommt man ein ziemlich verschobenes Bild.

Du meinst also, man erhält kein verschobenes Bild, wenn man Werte vorgesetzt bekommt, die von der Tau-Phase abhängen? Das ist wenig nachvollziehbar. Verschoben erscheinen mir eher mal wieder deine Sichtweisen.

Um konkret zu werden hatten sie einen 5900X mit dem 11900K (der Zehnkerner intel war es aufjedenfall) verglichen, um die Effizienz der einzelnen CPU Kerne aufzuzeigen. Alleine, dass man nicht den gleichen Corecount verwendet finde ich für Vergleichszwecke schon sehr unseriös und zum anderen greift man gezielt die Schwachstelle des AMD Konzepts für den Vergleich auf, da ich bei zwei Chiplets deutlich mehr Energie für die Kommunikation innerhalb der CPU benötige.

Gut, ist schon lustig, das so zu lesen. Dave vergleicht ja hier auch unterschiedliche Core Counts (was völlig legitim ist!), aber das ist dann wiederum seriös?

 

[PCGH_Dave]

Irgendwas scheint an den Diagrammen aber auch noch nicht zu stimmen, sie sind nicht immer richtig sortiert. Man muss teils noch mal manuell auf den Sortierwert klicken (auch um aufsteigend/absteigend zu wechseln), damit die Reihenfolgen passt.

Dieser Bug wurde gerade behoben, die Sortierung sollte jetzt korrekt sein