News Bobcat-Nachfolger Jaguar bekommt Unterstützung für AVX

[gruffi]

Hmm, auf der Roadmap vom AFDS steht wirklich "up to 4 Jaguar cores". Hatte noch die vom FAD Anfang des Jahres im Kopf. Da stand noch was von lediglich 2 Kernen. Was nun?

 

[Opteron]

Hmm, auf der Roadmap vom AFDS steht wirklich "up to 4 Jaguar cores". Hatte noch die vom FAD Anfang des Jahres im Kopf. Da stand noch was von lediglich 2 Kernen. Was nun?

Wenn sie sich am Namen verschreiben, ist ein Tippfehler bei der Kernanzahl nicht weit

 

[Crashtest]

War doch so geplant !

Ontario - Dualcore in 40nm Bulk Bobcat
Krishna - Dualcore in 28nm Bulk als Bobcatshrink + teilw. SOC
Jaguar - Quadcore in 28nm Bulk mit neuem Kern + teilw. SOC

Krishna wurde weggelassen - aber sonst stimmt noch der Plan

 

[hoschi_tux]

Jetzt ist die News auch bei Golem vertreten.

 

[Opteron]

Jetzt ist die News auch bei Golem vertreten.

Oh graus ... den SSE-Hinweis haben sie im Artikel nicht gesehen, und die Kommentare mit tex_s SSE-Fund erst recht nicht. Und dann noch der Absatz:

Das Design, das mit den APUs "Kabini" (Notebooks) und "Temash" (Tablets) nach AMDs letzter Roadmap im Jahr 2013 mit 28-Nanometer-Fertigung erscheinen soll, könnte daher von Bulldozer abgeleitet sein.

Ganz bestimmt

Ich glaub da muss ich noch ein Update schreiben ...

 

[SPINA]

Wird wohl wirklich nur auf ISA Kompatibilität hinauslaufen.

Allein das wäre mir bei einer Kaufentscheidung schon ziemlich viel wert. Ich denke an meinen guten, alten AMD Athlon Thunderbird ohne iSSE Erweiterung. Nach ein paar Jahren wurde das schon zu einem Problem, weil manche Software einfach den Start verweigert hat, da sie iSSE zwingend vorausgesetzt hat. Das war überwiegend Multimedia Software, wie RawTherapee. Das System hatte genug Arbeitsspeicher und war an für sich leistungsfähig genug. Allein die fehlende iSSE Erweiterung hat dann die Nutzbarkeit eingeschränkt. Deswegen musste ich dann immer öfter auf mein Notebook mit Intel Pentium M ausweichen. Einige Jahre zuvor soll dasselbe mit MMX geschehen sein. Das habe ich jedoch nicht so sehr mitbekommen, weil ich der Zeit immer einen halbwegs aktuellen Prozessor hatte. Seit dem AMD Athlon Thunderbird achte ich jedenfalls immer auf einen halbwegs modernen Instruktionssatz. Die Zugewinn an Leistung ist mir da zweitrangig. Mir kommt es allein auf die Zukunftssicherheit (ohne irgendwelche Klimmzüge) an. Leider hatte mein Mainboard damals auch keinen AMD Athlon XP mit Palomino Kern oder neuer und iSSE unterstützt. Und dass AMD nun AVX in allein Leistungsklassen bietet, ist sehr löblich. Intel beschneidet sogar kleinere Modellreihen manchmal künstlich.

 

[Opteron]

So Update ist draußen:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1343138045#Update

@Spina:
Ja so oder so ist es nicht schlecht, v.a. AES ist toll, finde ich - solange es auch wie (üblich) deutlich schneller ist

Allerdings bin ich gespannt, obs nicht doch 128bit Pipes werden. Bei 64bit müsste der Decoder 256bit AVX-Instruktionen in 4x64bit Ops übersetzen. Bei 2 Fastpath-Decoder wäre das Front-End damit für 2 Takte voll belegt - für nur eine x86-Instruktion. Bin mir nicht sicher, ob die Auswirkungen davon nicht zu groß werden. Alternativ könnte man auch einfach wieder nen dritten Decoder verbauen, aber das kostet auch wieder Fläche. Dann lieber mehr FPU-Leistung. Außerdem hat der Atom auch schon 128bit, wenn ich mich recht erinnere, nur der in-Order-Modus bremst da. Sicher ist aber natürlich nichts, möglich das AMD den Fall auch für ne kleinere Die-Fläche in Kauf nimmt.

 

[Duplex]

Außerdem hat der Atom auch schon 128bit, wenn ich mich recht erinnere, nur der in-Order-Modus bremst da.

Nächstes Jahr wird das Design durch OoO abgelöst, dann ist In-Order bei Intel endlich Geschichte . Ich gehe von 80% Nehalem Performance aus, der neue Atom "Silvermont" erreicht dann evtl. Core2 / K10 IPC
Eine 64 Bit FPU wäre für AMD nicht so toll wenn Intel tatsächlich einen größeren IPC Sprung vollziehen kann, beim K8 Refresh aka Barcelona war eine 128 Bit FPU auch kein Problem da sowieso eine neue Fertigung bereit steht.
Die Leistungsaufnahme sollte durch 28nm eig. deutlich niedriger als 40nm ausfallen, hier besteht viel Spielraum.

 

[SPINA]

Nächstes Jahr wird das Design durch OoO abgelöst, dann ist In-Order bei Intel endlich Geschichte .

Noch nicht ganz, denn da ist noch der Itanium 2, der wie der Sun UltraSPARC T2 auf eine in-order Pipeline setzt.
Von den Schwergewichten setzt nur der IBM POWER7 auf out-of-order. Der Vorgänger POWER6 noch nicht.

Andererseits kommt der Itanium 2 mit in-order gut zurecht, wegen des hochoptimierten Codes in seinem Alltag.
Es ist nicht so, dass sich ein Itanium 2 mit schlecht angepasster 08/15-Software abplagen müsste wie ein Atom.

 

[gruffi]

Von den Schwergewichten setzt nur der IBM POWER7 auf out-of-order. Der Vorgänger POWER6 noch nicht.

Der POWER6 war aber eher ein "Ausreisser". Meines Wissens waren die Vorgänger, POWER1-5, auch schon OoO.