News AMD Analystentag 2012, der Tag danach: Piledriver 10h & 20h; Fragezeichen bei 28nm CPU-Updates

Anpeilen und liefern sind zwei verschiedene Dinge... Haben die für den Bulldozer nicht auch mal 2009 angepeilt? ;)
 
Anpeilen und liefern sind zwei verschiedene Dinge... Haben die für den Bulldozer nicht auch mal 2009 angepeilt? ;)
ja, aber das war ja der andere Hauptpunkt, dass AMD jetzt pünktlich liefern will.

Aber hast schon recht, mal schauen, wie das am Ende ausgeht ^^
 
Allerdings ist die zusätzliche Unterstützung recht mager. Ganze zwei Befehle werden bei aktuellen Bulldozer der ersten Generation unterstützt, "LEA" sowie Increment- / Decrement-Instruktionen (INC/DEC). Letzteres sind primitive Additionen bzw. Subtraktionen mit dem festen Wert 1, C++-Programmieren bestens durch den "i++" oder "i--" Syntax bekannt. Mit der Familie 20h wird dieser Ansatz nun aber etwas ausgebaut. Ab sofort machen die AGLUs Ihren Namen etwas mehr Ehre, denn es werden nun immerhin folgende fünf Befehle zusätzlich unterstützt
Nun ja, die Anzahl der Instruktionen ist doch eher nebensächlich. Viel wichtiger ist, wie oft die Instruktionen genutzt werden. Und bis auf MOV ist da nichts interessantes bei den zusätzlichen Instruktionen dabei. Also ziemlich vernachlässigbar. Wobei ich mich frage, wird MOV nicht jetzt schon unterstützt? Und wenn XADD unterstützt wird, warum nicht auch ADD und SUB? Die wären wesentlich wichtiger.

Noch ein kleines semantisches Schmankerl zum Schluss. Auch wenn die Aussage im Artikel nicht falsch ist, strikt genommen ist das C++ Äquivalent zu INC/DEC ++i/--i. Oder in Pseudocode:

x = ++i
Code:
i = i + 1
x = i

x = i++
Code:
tmp = i
i = i + 1
x = tmp

;)
 
Nun ja, die Anzahl der Instruktionen ist doch eher nebensächlich. Viel wichtiger ist, wie oft die Instruktionen genutzt werden. Und bis auf MOV ist da nichts interessantes bei den zusätzlichen Instruktionen dabei.
Naja, wobei das auch "nur" reg<>reg MOVs sind, meistens wird man MOV aber doch mit ner Speicherstelle nutzen. Aber egal, besser als nix :)

Wobei ich mich frage, wird MOV nicht jetzt schon unterstützt? Und wenn XADD unterstützt wird, warum nicht auch ADD und SUB? Die wären wesentlich wichtiger.
Das hab ich mich auch gefragt, als ich es sah. Konnte mit XADD nix anfangen, und habs gegoogelt, Treffer hier:
http://siyobik.info/main/reference/instruction/XADD

Also ein ADD plus ein Vertauschen der beiden Register. Ergo mehr als ein normales ADD ... sehr mysteriös ... *noahnung*
Noch ein kleines semantisches Schmankerl zum Schluss. Auch wenn die Aussage im Artikel nicht falsch ist, strikt genommen ist das C++ Äquivalent zu INC/DEC ++i/--i. Oder in Pseudocode:

x = ++i
Code:
i = i + 1
x = i

x = i++
Code:
tmp = i
i = i + 1
x = tmp

;)
Danke, ich versuchs mir zu merken ^^
 
Ich verstehe den Sinn des Satzes nicht? Wieso willst du Äpfel (CPU) mit Birnen (APU) vergleichen? Was bewegt dich dazu?
 
Ich verstehe den Sinn des Satzes nicht?

Ok, dann formuliere ich ihn mal um. Es ist völlig sinnfrei, die Energieeffizienz anhand der TDP zu bewerten. Es ist ebenso sinnfrei, die EE anhand der Leistungsaufnahme in synthetischen Benchmarks zu beurteilen.

Wieso willst du Äpfel (CPU) mit Birnen (APU) vergleichen? Was bewegt dich dazu?

Das war nicht meine Intention sondern eine Reflektion dessen was ihr meines Erachtens gerade macht. Siehe oben.
 
Ok, dann formuliere ich ihn mal um. Es ist völlig sinnfrei, die Energieeffizienz anhand der TDP zu bewerten.
Tut auch niemand!
Es ist ebenso sinnfrei, die EE anhand der Leistungsaufnahme in synthetischen Benchmarks zu beurteilen.
handbrake ist kein synthetischer Bench!
Bei 3Ghz und 4 Cores bietet es sich an die zur Verfügung stehende Leistung abzurufen!

Das war nicht meine Intention sondern eine Reflektion dessen was ihr meines Erachtens gerade macht. Siehe oben.
Was spricht dagegen nur den CPU-Teil einer APU [ohne Vergleich auf herstellerübergreifende Modelle] zu bewerten?
 
Naja, wobei das auch "nur" reg<>reg MOVs sind, meistens wird man MOV aber doch mit ner Speicherstelle nutzen.
Ob sich das auch im Code widerspiegelt, kann ich dir nicht sagen. Aber sicherlich sind MOVs in Verbindung mit einer Speicheradresse der sinnvollere Fall. Denn hat man erstmal einen Wert in einem Register, möchte man damit rechnen und nicht wieder woanders hinschieben. Deshalb wundert es mich, dass man wirklich grundlegende Rechenoperationen nicht in die AGLUs implementiert, wie logische Verknüpfungen (AND, OR, XOR), arithmetische Operationen (ADD, SUB) und Shifts (SHL, SHR, SAL, SAR). Das sind alles vergleichsweise simple Sachen, die wenig Transistoren und Energie kosten. Sicherlich kann man einiges davon auch über LEA realisieren. Nur ist das keine optimale Lösung, da das der Compiler wissen muss.
 
Tut auch niemand!

Gut zu wissen.

handbrake ist kein synthetischer Bench!
Bei 3Ghz und 4 Cores bietet es sich an die zur Verfügung stehende Leistung abzurufen!


Was spricht dagegen nur den CPU-Teil einer APU [ohne Vergleich auf herstellerübergreifende Modelle] zu bewerten?

Dagegen spricht das es in diesem Teil des Threads ( bis http://www.planet3dnow.de/vbulletin/showpost.php?p=4561492&postcount=11 hab ichs zurück verfolgt )
nicht um eine theoretische Betrachtung der Architektur bzw. der APU geht sondern um die Chancen am Markt.

Für die Masse der Käufer ist Handbrake eben m.E. völlig ohne Belang, ebenso wie die Bewertung des CPU-Teils einer APU. Diese Masse interessiert die Leistung die hinten raus kommt wenn sie ihre Allerweltssachen machen. Und frag mich nicht nach einer Definition dieser Allerweltssachen, ich will mir nicht anmassen eine solche zu geben.
 
Es ging mir allein um deine Pauschalisierung, welche eben nicht auf alle LLanos zutrifft.
Besonders auf das 2.9 und 3.0Ghz 4 Kern Modell. Und jetzt komm mir nicht mit der Argument des nicht Ausnutzens.
Wenn das so wäre, bräuchte man diese dicken Modelle nicht. (Wenn ich mir einen Porsche kaufe, dann doch nicht um ihn bei niedrigen Drehzahlen verbrauchsarm über die Straße zu tragen).
Da würde Brazos bzw. ein 2 Kern LLano mit mittleren Takt reichen. Und ja diese Modelle sind mMn Energieeffizient.

Handbrake war nur ein Beispiel.
Auf dem System läßt sich aber auch sehr gut Supreme Commander Forged Alliance und einigermaßen Supreme Commander 2 gut spielen, mit onboard GPU versteht sich.
Beide Games lasten 1-2Kerne zu 100% aus. Daher taktet das System durchgehend mit 3Ghz.
Das sollte eigentlich auf jedes Game zutreffen ;)
 
Zuletzt bearbeitet:
Es ging mir allein um deine Pauschalisierung, welche eben nicht auf alle LLanos zutrifft.

Deine Meinung. Ich sehe weiterhin keine Möglichkeit die EE einer CPU/APU anhand von deren TDP zu bestimmen.

Besondern auf das 2.9 und 3.0Ghz 4 Kern Modell. Und jetzt komm mir nicht mit der Argument des nicht Ausnutzens. Wenn das so wäre, bräucht man diese dicken Modelle nicht. (Wenn ich mir einen Porsche kaufe, dann doch nicht um ihn bei niedrigen Drehzahlen verbrauchsarm über die Straße zu tragen).

Dir ist aber schon bewußt das es weiterhin um die Bereiche geht in denen die Absatzzahlen ein paar Nullen mehr haben und das hier die Kunden eher weniger auf konkreten Bedarf hin kaufen?


(Und nein, ich glaube nicht das die Durchschnittsgeschwindigkeit mit laufendem Motor aller in 2011 verkauften Porsche mehr als 80km/h beträgt)


Handbrake war nur ein Beispiel. Auf dem System läßt sich aber auch sehr Supreme Commander Forged Alliance und einigermaßen Supreme Commander 2 gut spielen, mit onboard GPU versteht sich.
Beide Games lasten 1-2Kerne zu 100% aus. Daher taktet das System durchgehend mit 3Ghz.

Ist das mittlerweile so? google spricht von deutlich geringerer Last ab dem zweiten Core.
 
Mit Supreme Commander 1 habe ich auch schon 4 Kerne ausgelastet. Den 2. habe ich noch nicht gespielt.
 
Deine Meinung. Ich sehe weiterhin keine Möglichkeit die EE einer CPU/APU anhand von deren TDP zu bestimmen.
Das tust nur du. Ich messe den Verbrauch mit einem Messgerät.
Dir ist aber schon bewußt das es weiterhin um die Bereiche geht in denen die Absatzzahlen ein paar Nullen mehr haben und das hier die Kunden eher weniger auf konkreten Bedarf hin kaufen?
Deswegen werden die *bestimmten* LLanos nicht effizienter, nur weil sie nicht ausgenutzt werden.
(Und nein, ich glaube nicht das die Durchschnittsgeschwindigkeit mit laufendem Motor aller in 2011 verkauften Porsche mehr als 80km/h beträgt)
Glauben ist gut, belegen ist besser!
Ansonsten bleibe ich bei meiner Meinung *buck*

Ist das mittlerweile so? google spricht von deutlich geringerer Last ab dem zweiten Core.
SC1 und SC2 haben einen Thread festgepinnt auf einen Core und lasten diesen zu 100% aus.
Darüberhinaus wird ab und an ein 2. CPU-Kern benötigt. Extreme Ausnamhe sind Schlachten mit 7 CPU-Gegnern, da limitiert allein die CPU.
Ich hatte da mal im CPU-Forum zusammen mit Stechpalme einen SkalierungsBenchen von 1-4 Kernen veröffentlicht.

Mit Supreme Commander 1 habe ich auch schon 4 Kerne ausgelastet. Den 2. habe ich noch nicht gespielt.
Stimmt. im Mehrspielermodus mit 4-5 CPU-Gegnern ist das durchaus möglich.
Das SC2 ist leider GPU-Limitiert, benötigt einen ganzen CPU-Kern und ab und an einen halben zusätzlich.
 
Zuletzt bearbeitet:
Ob sich das auch im Code widerspiegelt, kann ich dir nicht sagen. Aber sicherlich sind MOVs in Verbindung mit einer Speicheradresse der sinnvollere Fall. Denn hat man erstmal einen Wert in einem Register, möchte man damit rechnen und nicht wieder woanders hinschieben. Deshalb wundert es mich, dass man wirklich grundlegende Rechenoperationen nicht in die AGLUs implementiert, wie logische Verknüpfungen (AND, OR, XOR), arithmetische Operationen (ADD, SUB) und Shifts (SHL, SHR, SAL, SAR). Das sind alles vergleichsweise simple Sachen, die wenig Transistoren und Energie kosten. Sicherlich kann man einiges davon auch über LEA realisieren. Nur ist das keine optimale Lösung, da das der Compiler wissen muss.
Gute Frage, vielleicht wars ja mal so angedacht, aber es kam was dazwischen. Man darf nicht vergessen, Bulldozer hat erst Revision B2. Das ist doch eigentlich nichts. Außerdem ist dann da noch der Decoder, der ein Engpaß zu sein scheint. Im Moment nur 4+1 oder schlimmstenfalls gar nur 2 Ops pro Takt, und das für 2 INT Cluster plus FP-Unit. Da hülfen auch 10 Pipes nichts, wenn der Dec. nicht liefern kann.

Mal schauen was Steamroller liefert. Da gabs ja das "sichere" Gerücht mit den extra Decodern pro Cluster. Sollte das Ganze dann wohl schon entspannen, und auch die AGLUs könnten dann ausgebaut werden.
 
Klingt für mich als wollte man das selbe was man vorher mit den GPUs gemacht hat jetzt auch mit den CPUs machen wollen.

Kleinere einfachere designs die P/L mäßig unschlagbar sind.

Und bei den GPUs hat diese Strategie sogar an die Leitungsspitze zurückgeführt.
 
Zurück
Oben Unten