AMD will 2010 Intels Atom-Plattform Konkurrenz machen

mr.dude · 12.06.2009

Undertaker 1 schrieb:
Es ist eine ganz einfache Frage: Warum unterstützt es der eine Decoder, warum der andere nicht

Was genau soll denn der Decoder unterstützen? Und das ist auch keine Frage zu deiner ursprünglichen Aussage, wo angeblich "auf exzessive spekulative Ausführungen verzichtet" worden sein soll. Das würde bedeuten, dass ein solches Design bzw In-Order allgemein dies bedingt. Ich sehe dafür aber keine Basis. Weder grundsätzlich, noch beim zugrunde liegenden Design. Wie ich schon sagte, man verzichtet auf viele solcher aufwendigen Sachen, weil es das Wesen eines solchen Design Ansatzes ist.

Undertaker 1 · 12.06.2009

Ähm, auch ein Sprungziel bei spekulativer Ausführung muss decodiert werden. Der eine Decoder des Atom decodiert solch spekulative Sprünge, der andere wie auch Anandtech schreibt, aus Energiespargründen nicht. Das ist kein Käse, sondern wurde von anderen Seiten wohl nur nicht so detailiert beleuchtet.

mr.dude · 12.06.2009

Nochmal, Decoder zerpflücken µOps, entsprechend den x86 Spezifikationen. Ende der Geschichte. Da wird weder gesprungen, noch spekuliert, noch sonst irgendetwas.
Also entweder weiss Anandtech nicht, was sie schreiben. Oder sie drücken sich falsch aus. Du solltest nicht alles für bare Münze nehmen, was sie schreiben. Für solche Themen würde ich ausserdem kompetentere Quellen empfehlen.

[HOT] · 12.06.2009

In-Order ist nicht flexibel. Was daraus folgt sollte klar sein. Da kann man eh nicht spekulativ arbeiten, weil man dadurch bei in-Order eh nichts gewinnt. Bei in-Order funktioniert eine CPU klassisch: Ein Befehl+Daten werden geladen, werden gerechnet und das Ergebnis gespeichert - Ende der Geschichte. Simpler gehts nicht, deswegen ist diese Technik so billig (aber auch nur dann, wenn man sie nicht wieder mit was anderem aufbläht). Allerdings finde ich das Vorgehen in Zeiten von 45nm-Produktion und Powersaving-Möglichkeiten ziemlich bescheuert, man kann bequem genauso leistungsfähige CPUs mit weniger Takt im OoO-Design bauen, macht mMn deutlich mehr Sinn. Intel ging es ja auch nur im die Die-Fläche, sonst hätten sie diesen Unfug nicht so auf den Markt gelassen. Wirtschaftlich betrachtet ist der Schuss ja auch nach hinten losgegangen, weil man den kleineren PC-Plattformen das Wasser abgegraben hat mit dem Atom, Atom also die Profite eher geschmälert als gefördert hat.
Decoder gabs schon in den alten Pentiums. Das gibts ja auch nur, weil es sich nicht lohnt, x86-CISC-Code nativ zu rechnen, hat also nichts mit dem CPU-Design als solches zu tun, nur insofern, dass man einen CISC/RISC-Mischling bauen kann. Ob in-Order oder OoO und welche Techniken dahinter und davor benutzt werden ist den Decodern vollkommen egal.

Opteron · 12.06.2009

Undertaker 1 schrieb:
Das ist kein Käse, sondern wurde von anderen Seiten wohl nur nicht so detailiert beleuchtet.

Ich mach jetzt ne Seite auf, in der behauptet wird Merkel sei ein nordkoreanischer Klon. Das stimmt dann sicher auch, und die andren Seiten haben das nur nicht so detailliert beleuchtet ... :asthanos:

Im Ernst, les Dich mal in die Materie ein, dann wirst Dus einsehen. Falls nicht dann hören wir an dem Punkt auf, macht keinen weiteren Sinn. Du hast Deine Meinung ich meine. Das wars dann.

@HOT:
Jein ... es macht in der Hinsicht sinn, dass man Energie sparen kann. Die Spekulationen gehen auch schon mal schief und die ganze Berechnung / Energieaufwand war fürn Popo.
Um die Rechenwerke jetzt besser auszulasten nehmen sie SMT her. Ist prinzipiell ein netter Ansatz, SMT bringt beim Atom ja auch deutlich mehr als bei, P4 oder i7, aber die single thread Leistung leidet darunter eben ziemlich.

Wäre das ganze etwas schneller getaktet, sagen wir mal ~2,5 GHz, und bekäme das Teil nen ordentlichen FSB, könnte das ne schöne Desktopkiste werden, aber das will Intel ja nicht ...
Der Stromverbrauch wäre dann zwar wieder bei um die 10W, aber es bliebe der Fertigungsvorteil.

ciao

Alex

Undertaker 1 · 12.06.2009

mr.dude schrieb:
Nochmal, Decoder zerpflücken µOps, entsprechend den x86 Spezifikationen. Ende der Geschichte. Da wird weder gesprungen, noch spekuliert, noch sonst irgendetwas.
Also entweder weiss Anandtech nicht, was sie schreiben. Oder sie drücken sich falsch aus. Du solltest nicht alles für bare Münze nehmen, was sie schreiben. Für solche Themen würde ich ausserdem kompetentere Quellen empfehlen.

Argh. Lesen -> verstehen. Wenn spekulativ gesprungen wird (ich hoffe du weißt was spekulative Ausführung überhaupt bedeutet?), muss auch decodiert werden, das ist dir hoffentlich klar. Und das wird eben nicht in jedem Fall gemacht, Ende der Geschichte. Alles klar soweit?

fromhell101 · 13.06.2009

..........

mr.dude · 13.06.2009

LOL, Undertaker du bist wieder mal auf einem Kreuzzug der Unwissenheit. Deine Aussage ergibt keinen Sinn. Geschweige denn, dass sie eindeutig formuliert ist. Na ja. Macht keinen Sinn, an der Stelle weiter zu diskutieren, wenn Ignoranz über Vernunft siegt. :rolleyes:

Nur zur Information, was dekodiert wird, bestimmt der Prefetcher. Die Decoder selbst arbeiten stur nach Schema F. Ob gesprungen wird oder nicht, ist denen sowas von egal.

Opteron · 13.06.2009

Hmmm hab jetzt mal noch ein bisschen gesucht ... verdammt schwierig da Information zu finden wo denn nun die Spekulation ausgeführt wird ...

So wies ausschaut hat Undertaker allerdings recht .. zumindest wenn man die VIA Nano Quelle heranzieht, die geben dessen Aufbau so an:

Die Branch Prediction, versucht die Verzweigungen vorherzusagen und führt die dann nach bester Vorhersage aus ... das ist dann die "berüchtigte" speculativ execution.

Macht prinzipiell den Anand Satz hier aber nicht besser:

Atom's slow decoding path does not include any speculative decoding.

Er hätte da besser geschrieben, dass die Branch prediction Verzweigungen mit komplexen Befehlen einfach links liegen läßt. Macht auch Sinn, denn die würde den ganzen Decoder aufhalten. Da man aber SMT hat, läßt man lieber fast-path Instr. des 2ten Threads zu, bevor man "komplex herumspekuliert" ^^

Was dann nach den Decodern passiert ist die Out of Order Execution ... wenn Atom eine OoO CPU wäre ;-)

Zuviel Executions ^^

ciao

Alex

[HOT] · 13.06.2009

Ähm der Nano ist aber OoO, wie das Schema auch zeigt... Decoding und der µOp-Sortierkäse sind immer in Order.

Opteron · 13.06.2009

[HOT] schrieb:
Ähm der Nano ist aber OoO, wie das Schema auch zeigt...

Jo, der ist OoO ... aber das hat nix mit Spekulation zu tun, der Atom hat auch ne Branch Prediction.

Wie Du oben am Nano Schema siehst, ist der obere Teil inkl. Spekulation in-order, OoO kommt dann später in den Reorder Buffers, nach der µOp Queue. Sowas hat Atom dann nicht, wohl aber die Branch Prediction vor den Dekodern.

ciao

Alex

mr.dude · 13.06.2009

Ging es nicht um die Decoder? Zumindest laut Aussage von Undertaker. Das ist zwar alles Frontend, die haben mit spekulativer Ausführung aber nichts zu tun. Decoder, Prefetcher und Branch Unit sind separate Einheiten.

Hier mal der konkrete Aufbau vom Atom:

Und sollte Atom tatsächlich auf einem alten P5 basieren, braucht man gar nicht auf spekulative Ausführung verzichten. Denn das konnte der P5 noch gar nicht.

Opteron · 13.06.2009

mr.dude schrieb:
Ging es nicht um die Decoder? Zumindest laut Aussage von Undertaker. Das ist zwar alles Frontend, die haben mit spekulativer Ausführung aber nichts zu tun. Decoder, Prefetcher und Branch Unit sind separate Einheiten.

Jo, aber den Mist mit den Dekodern hat Anand verbrochen ...

Undertaker 1 · 14.06.2009

Opteron schrieb:
So wies ausschaut hat Undertaker allerdings recht .. zumindest wenn man die VIA Nano Quelle heranzieht, die geben dessen Aufbau so an:
http://www.abload.de/img/nanoffz0.png

Na also, sind sich jetzt alle wieder einig und sehen ihre Fehler ein :wink:

mr.dude · 14.06.2009

Du siehst deine Fehler ein? Ist ja was ganz neues. Welche waren es nochmal? :rolleyes:

Undertaker 1 · 14.06.2009

Du kannst ja anderer Meinung als Opteron und ich sein, aber wollen wir den Zoff jetzt nichtmal beenden und zum Thema zurückkehren? :wink:

mr.dude · 14.06.2009

Du scheinst wohl die Sachlage leicht zu missverstehen. Ich war nie anderer Meinung als Opteron. Du schon. Der einzige, der hier Fehler einsehen sollte, bist du. Und wenn schon nicht fachliche, dann den gut gemeinten Rat, dass du nicht alles glauben solltest, was Anandtech schreibt. Was natürlich erstmal wieder stur gegenargumentiert wurde. :rolleyes:

Undertaker 1 · 14.06.2009

Ich kanns ja auch gerne nochmal verlinken:

http://www.abload.de/img/nanoffz0.png

Jetzt sollten wir das aber wirklich beenden, meinst du nicht?

mr.dude · 14.06.2009

Und was soll der Link beweisen? Du hast offenbar nicht mitbekommen, dass das irrelevant fürs Thema ist. Die Architektur zum Atom habe ich oben gepostet. Die Decoder haben jedenfalls immer noch nichts mit spekulativer Ausführung zu tun.

Undertaker 1 · 14.06.2009

Ganz wie du das sehen möchtest, natürlich

So lange du der einzige bist der mir widerspricht - die Zustimmung von anderer Seite konntest du ja sehen - ist ja alles im Lot.

Um jetzt mal wieder zum Thema zu kommen:

http://www.hardware-infos.com/news.php?news=3010

Wie es scheint wird die Messlatte für AMDs Konkurrenten auf 7W TDP (Plattform) sinken. Kennt jemand TDPs von aktuellen AMD Mobil-Chipsätzen (nur Chipsatz)?

mr.dude · 14.06.2009

LOL, ist ja echt peinlich. Du liest offenbar nur das, was du lesen möchtest. Opteron hat dir zu unrecht zugestimmt, weil er von einem falschen Vorsatz ausgegangen ist.

Undertaker 1 · 14.06.2009

Nein. Auch beim Atom erfolgt die Befehlcodierung nach dem Sprung. Dem widerspricht auch dein obiges Bild von Anandtech nicht. Wenn du meine Beiträge nicht verstehst tut mir das herzlich Leid

mr.dude · 14.06.2009

Du hast explizit von spekulativer Ausführung in den Decodern gesprochen. Und das ist schlichtweg nicht korrekt. Rausreden hilft dir da nicht weiter.
Andere Quellen sprechen übrigens sogar davon, dass Atom grundsätzlich keine spekulative Ausführung beherrscht. Also nicht nur ein Decoder oder was immer du auch glauben magst zu wissen.
Du weisst schlichtweg so gut wie nie, wovon du eigentlich sprichst, und plapperst nur das nach, was du auf irgendwelchen Internetseiten findest. Bist aber nicht in der Lage, auch mal auf andere Leute zu hören. Das ist dein Problem.

Undertaker 1 · 14.06.2009

mr.dude schrieb:
Du hast explizit von spekulativer Ausführung in den Decodern gesprochen.

Ach, wenns nicht anders geht denkst du dir jetzt aus was ich gesagt haben soll? Pffft.

http://www.hardwareluxx.de/community/showpost.php?p=12219964&postcount=36

che new · 14.06.2009

Opteron schrieb:
Jo, aber den Mist mit den Dekodern hat Anand verbrochen ...

Fragt sich nur warum der der das nachgeplappert hat dann nun auf Rechthaben pocht.

mr.dude · 14.06.2009

@Undertaker

Bleib mal schön bei den Tatsachen.

Der Verzicht auf spekulative Ausführung betrifft nur einen der beiden Decoder des Atoms, eine bewusste Design-Entscheidung.

Nun, was denkst du wohl warum der 2. (oder eben 3.) Decoder auf die spekulative Ausführung verzichtet?

Warum verzichtet man bei den/dem "langsamen" Decoder auf die spekulative Ausführung?

Warum unterstützt es der eine Decoder, warum der andere nicht

Reicht das? Oder soll ich noch mehr zitieren?
Decoder dekodieren, ganz simpel, immer stur nach dem gleichen Schema. Die spekulieren nicht. Alleine schon deine Formulierung "decodiert solch spekulative Sprünge" zeigt, dass du keine Ahnung von der Materie hast. Dekodiert werden grundsätzlich Instruktionen. Und das ist bei spekulativer Ausführung nicht anders. Aufgrund eines Sprunges wird von der Branch Unit spekuliert. Und die im Voraus spekulierten Instruktionen, nämlich die, die der IP an der Stelle nach dem Sprung vorfindet, werden genauso stur von den Decodern behandelt wie andere auch. Was also dekodiert wird, bestimmen Branch Unit und Prefetcher, nicht aber die Decoder selber.
Aber wir drehen uns ja im Kreis. Das wurde alles schon mal gesagt. Ich bin ja mal gespannt, ob du irgendwann ein Einsehen hast, dass du entweder von einem falschen Vorsatz ausgegangen bist oder dich bei der Formulierung vertan hast. Wäre zumindest schon mal ein Anfang. :rolleyes:

Undertaker 1 · 14.06.2009

Ach mein lieber Dude, lesen und verstehen. Es geht darum, ob bei einem Sprung anschließend decodiert wird oder nicht. Dies ist beim Atom anscheinend nicht immer der Fall.

Opteron · 14.06.2009

Undertaker 1 schrieb:
Ach mein lieber Dude, lesen und verstehen. Es geht darum, ob bei einem Sprung anschließend decodiert wird oder nicht. Dies ist beim Atom anscheinend nicht immer der Fall.

Das ist jetzt falsch, wenn geprungen wird, dann wird in jedem Fall decodiert .. ansonsten kommst Du nicht recht weit mit dem Code ;-)

Rein von der Logik her muss Anand meinen, dass nicht *spekulativ* "gesprungen" wird, wenn der komplexe Decoder benützt werden müßte.
In Pseudocode irgenwie so:

If Detect.ComplexInstr() = true then
BranchPrediction = false.

Die Decoder decodieren wirklich nur ^^
Wann *spekulativ" gesprungen wird, bestimmt die Branch Pred.. Die Decoder fressen alles was sie von der oder den Fetch Units bekommen.

Langsam könnte wir aber wirklich mit dem Thema aufhören sollte doch klar sein, dass die Decoder nichts andres machen. Ansonsten würden sie nicht "Decoder" heißen :asthanos:

ciao

Alex

Undertaker 1 · 14.06.2009

Opteron schrieb:
Das ist jetzt falsch, wenn geprungen wird, dann wird in jedem Fall decodiert .. ansonsten kommst Du nicht recht weit mit dem Code ;-)

Es scheint, also wird genau hier die Abarbeitung abgebrochen, eben um den Energieverbrauch zu senken - denn spekulativ kann eben auch einmal falsch sein. Ergo: Einer der der Decoder wird auch mit der Decodierung spekulativer Sprungziele gefüttert, der andere (wenn es denn 3 sind, die beiden identischen hier zusammengefasst) nicht. In diesem Fall entfällt selbstverständlich auch Ausführung.

Opteron schrieb:
Rein von der Logik her muss Anand meinen, dass nicht *spekulativ* "gesprungen" wird, wenn der komplexe Decoder benützt werden müßte.

Exakt.

Opteron schrieb:
Langsam könnte wir aber wirklich mit dem Thema aufhören

Gerne. Dann endlich btt.

Opteron · 14.06.2009

Gerne. Dann endlich btt.

Jo jeder noch nen allerletzten Kommentar, wenns sein muss, und dann Ende ;-)
Hier noch meiner:

Undertaker 1 schrieb:
Es scheint, also wird genau hier die Abarbeitung abgebrochen, eben um den Energieverbrauch zu senken - denn spekulativ kann eben auch einmal falsch sein. Ergo: Einer der der Decoder wird auch mit der Decodierung spekulativer Sprungziele gefüttert, der andere (wenn es denn 3 sind, die beiden identischen hier zusammengefasst) nicht. In diesem Fall entfällt selbstverständlich auch Ausführung.

Jo so wies ausschaut wurde darüber jetzt die ganze Zeit gestritten, ob abgebrochen wird, oder erst gar nicht losgeschickt wird.
Ich bin eben auf den Standpunkt, dass die Dekoder dekodieren und sonst nichts.
Deinen Sachverhalt, dass sich die Dekoder darum kümmern würden, was sie spekulativ ausführen oder nicht, halte ich für viel zu kompliziert.

Rein von der Logik her, sollte man das Problem an der Wurzel also der Branch Pred. anpacken und erst gar keine spekulativen Sprünge mit komplexen Instruktionen abschicken. Das geht mit dem Zweizeiler Pseudocode von mir oben kinderleicht.
Ausserdem sitzt in der Branch Pred. schon ne Menge an Logikschaltkreisen. Das dort unterzubringen wäre die offensichtliche Wahl. Die Dekoder haben dagegen eben nur Dekoder-Schaltkreise.

Letztes Argument wäre der Stromverbrauch, wieso sollte man die Branch Pred. mühsam rumrechen lassen, bis die einen spekulativen Sprung mit complex Instr. auf den Weg schickt, der dann in der nächsten Stufe gleich abgebrochen werden würde ... -> seehr unpraktisch. Dem kann man mit dem complex Instr. Verbot, ganz am Anfang der Branch Pred. gleich nen Riegel vorschieben.

So das wars dann schönen Sonntag noch.

ciao

Alex

AMD will 2010 Intels Atom-Plattform Konkurrenz machen

Urgestein

Enthusiast

Urgestein

Enthusiast

Semiprofi

Enthusiast

Enthusiast

Urgestein

Semiprofi

Enthusiast

Semiprofi

Urgestein

Semiprofi

Enthusiast

Urgestein

Enthusiast

Urgestein

Enthusiast

Urgestein

Enthusiast

Urgestein

Enthusiast

Urgestein

Enthusiast

Enthusiast

Urgestein

Enthusiast

Semiprofi

Enthusiast

Semiprofi

Ähnliche Themen