Intel Sandy Bridge

Opteron · 23.09.2009

Hiho,

gerade war/ ist IDF und Intel hat ein Grobschema von SandyBridge präsentiert:

https://intel.wingateweb.com/us09/scheduler/catalog/catalog.jsp
(->ARCS002

.shoppingCartAddButton { border: 0px; position: relative; margin: 4px; }
How To Optimize Your Software For The Upcoming Intel® Advanced Vector Extensions (Intel® AVX))

Zum Vergleich, der Nehalem:

http://de.wikipedia.org/wiki/Intel-Nehalem-Mikroarchitektur

Viel tut sich da also nicht, die 256bit werden in 2x128bit aufgeteilt und auf 2 Piplines/Ports verteilt. Fürs Laden wird der Load Port verbreitert.

Weitere Konsequenzen aus dem aceshardware Forum von Eric Bron, "slide 6" bezieht sich auf obiges SBridge Bild:

1) slide 6, one "AVX HIGH" unit on port 0, and "AVX LOW" on port 1 => it looks like 256-bit AVX will have the same throughput than 128-bit SSE on current cores: 2 clocks for a 256-bit vmulps/pd + a 256-bit vaddps/pd instead of 1 clock for 128-bit mulps/pd + 128-bit addps/pd (i.e. same sp/dp flops per clock with balanced add/mul), so if Sandy Bridge can't issue in the same clock a mul and an add unlike Conroe, Penryn and Nehalem it will be actually less efficient than these previous cores with a lot of legacy 128-bit SSE code ?, if it's indeed the case Agner was pretty right after all

2) slide 6, only 128-bit paths from the L1D cache to execution units (I was hoping full featured 256-bit paths), a few consequences :
- the extra load port will help as much legacy 128-bit SSE or 128-bit AVX than 256-bit AVX, same 48 B / clock maximum L1 bandwidth
- loop fission will be probably no more a good optimization if intermediate results are stored in L1D, probably better to overflow the LSD than the L1D, particularly with multiple threads fighting for L1D access
- more incentive to use 64-bit code to have 16 ymm registers instead of 8 to minimize L1D access

3) slide 54, 64 B cache lines (unchanged), so :
- align memory still important (more important than on Nehalem), 1/2 access will incur a cache line split otherwise

4) slide 58, masked moves considered harmful, replace vmaskmovps by vblendvps + vmovaps just like in legacy SSE4 code ?

Edit:
Hmm, anscheinend verbreitet intel fehlerhaftes Material, gibt jetzt ne Antwort im Intel Forum:

1) The chart is wrong, we will fix it. Sandy Bridge has true 256-bit FP execution units (mul, add, shuffle). They are on exactly the same execution ports as the 128-bit versions. You can get a 256-bit multiply (on port 0) and a 256-bit add (on port 1) and a 256-bit shuffle (port 5) every cycle. 256-bit FP add and multiply bandwidth is therefore 2X higher flops than 128. See IACA for the ports on an instruction-by-instruction basis.
2) The chart doesn’t mention 16-byte paths. We have true 32-byte loads (i.e. each load only uses one AGU resource and we have 2 AGU’s) but only a 48-byte/cycle total is supported to the L1 each cycle. You can’t get 48 bytes per cycle to the DCU using 128-bit operations (only 2 agu’s…). This is why a simple memory-limited kernel like matrix add (load, load, add, store) measures 1.42X speedup (would have predicted 1.5X with the current architecture in the limit; vs. 1.0X if we had double pumped).
3) Alignment for 128-bit loads/stores is similar to Nehalem. The alignment penalty for 256-bit loads/stores is somewhat worse – that’s due to line splits and page splits. You are much more likely to split with wider loads, so alignment is much more important. That’s why, especially if you can guarantee 16 byte alignment but not 32-byte alignment, it often pays off to do load128/insertf128 instead of load256. Previous guidance to favor aligning stores (when you get a choice to align either a load or a store stream) still holds – store page splits are worse than load page splits.
4) Masked moves are not harmful, they are proving extremely useful. But they are designed for a specific problem – when the exception safety of nonmasked loads/stores can’t be guaranteed. They burn a blend resource, and they aren’t going to disambiguate as well as normal loads and stores, so I don’t use them when I don’t need them. If you are a vectorizing compiler, they’re great for peeling and remainder operations, vectorizing code with “if” protecting a possible exception, etc. If you are a human coder, I doubt you’ll need them: A bit of data overrun padding (often coupled with alignment) pays dividends in speed. You mention doing the blend yourself. Note that a variable blend requires 2 port-5 shuffles so in shuffle-limited code this doesn’t always win.

http://software.intel.com/en-us/forums/intel-avx-and-cpu-instructions/topic/68554/

Edit:
Vergleichsschaubild von Hans de Vries mit Sandy Die Shot:

ciao

Alex

Opteron · 13.02.2010

Damit hier auch mal wieder was steht, angeblich gibts nächstes Jahr Sockel 1155:

http://www.xbitlabs.com/news/cpu/di...ors_New_Infrastructure_in_Q1_2011_Source.html

Wobei Charlie aber von Socket-R redet:
http://www.semiaccurate.com/2010/02/05/intels-next-socket-nearly-doubles-pin-counts/
(Wird bei ~2000 Pins wohl eher ein Serversockel sein).

ciao

Alex

rkinet · 13.02.2010

Opteron schrieb:
Damit hier auch mal wieder was steht, angeblich gibts nächstes Jahr Sockel 1155:

http://www.xbitlabs.com/news/cpu/di...ors_New_Infrastructure_in_Q1_2011_Source.html

AVX erscheint mir auch recht performant.

Und die Verstärkung bei Load dürfte Vorteile des Bulldozer etwas mindern.
Bzgl. AVX kann man die Äußerungen von AMD die GPU verstärkt programmierbar zu gestelten als Gegenpart ansetzen. Wobei die Frage entsteht ob das schon der LIano bekommt oder erst sein 22nm Bullzozer + GPU Nachfolger ?

Bleibt auch die Frage ob AMD nicht wg. der jüngste Einigung mit Intel Zugriff auf die VAX Technik hat. Dann könnte auch Bulldozer sowas kompatibel erhalten - oder ?

Opteron · 13.02.2010

rkinet schrieb:
Bleibt auch die Frage ob AMD nicht wg. der jüngste Einigung mit Intel Zugriff auf die VAX Technik hat. Dann könnte auch Bulldozer sowas kompatibel erhalten - oder ?

Öh nö, die Frage stellt sich nicht, denn Bulldozer hat AVX, das wurde schon vor über nem halben Jahr offiziell verlautbart.

Blätter mal im Bulldozer Thread zurück, bzw. such da nach AVX.

ciao

Alex

Bobo_Oberon · 13.02.2010

Opteron schrieb:
Öh nö, die Frage stellt sich nicht, denn Bulldozer hat AVX, das wurde schon vor über nem halben Jahr offiziell verlautbart.

Blätter mal im Bulldozer Thread zurück, bzw. such da nach AVX. ...

Eben. "Viel" spannender ist die Entwicklung rund um den Larrabee und deren Instruktionssatzerweiterung ...

Wie früh wird AMD dieses einsetzen und darf AMD das überhaupt? Immerhin sind nun Test-Umgebungen mit Intels einstmaligen GPGPU-Buster im Umlauf. Aber Forschungschchips sind nun etwas anderes, als eine breit eingeführte Massenarchitektur.

MFG Bobo(2010)

Opteron · 13.02.2010

Bobo_Oberon schrieb:
Eben. "Viel" spannender ist die Entwicklung rund um den Larrabee und deren Instruktionssatzerweiterung ...

Jo, oder AMDs Eigenbau (=ATi) VLIW Instruktionssatz. Bin mal gespannt, wie das integriert wird.

rkinet · 13.02.2010

Opteron schrieb:
Öh nö, die Frage stellt sich nicht, denn Bulldozer hat AVX, das wurde schon vor über nem halben Jahr offiziell verlautbart.

Blätter mal im Bulldozer Thread zurück, bzw. such da nach AVX.

http://www.zdnet.de/news/wirtschaft..._hyperthreading_story-39001021-41522716-1.htm

Hat sich wohl noch nicht rumgesprochen ... 8)

Wie auch immer - solange nicht Intel erstes Sandy Bridge Silicium rum gehen läßt kann sich AMD nicht sicher sein ob alles auch so realisiert wurde wie ursprünglich dokumentiert.
Und ob der Bulldozer das auch richtig umsetzt Intel hatte ja auch bei x86-64 minimale Inkompatibilitäten beim ersten Silicum. Wenn AMD nun einen Fehler macht wäre die ganze Implemetierung erst im Folgestepping nutzbar.

Dr@ · 13.02.2010

Das hatte ich damals bereits kommentiert -> sie unter dem Artikel. Der Autor hat auch drauf geantwortet.

Die Patent- Probleme von denen er spricht, sollten sich ja mittlerweile erledigt haben.

MfG @

Opteron · 13.02.2010

Gute Güte was für schlechte Schreiberlinge (ein "Journalist" verkneif ich mir mal)...

Auszüge aus einem Blog Eintrag von Nigel Dessau vom 6. Mai (erster Treffer wenn man nach "amd avx" googelt):

(...)
Changing the instruction set can be both complex and expensive for application developers and painful for system designers. AMD recognizes this, and we are trying to reduce some of this cost and complexity by helping to unify the x86 instruction set with the adoption of the Advanced Vector Extensions (AVX).
(...)
Now, originally we had focused on what we had called SSE5, a specification we proposed for review by the industry in 2007. However, due to the overlap of functionality between the AVX instructions and SSE5, AMD has decided to recast the SSE5 instructions into the AVX framework. AMD made decision to ensure the continued compatibility of x86 software, and plans to incorporate AVX instructions into AMD processors in 2011.

a) "Adoption" ist eindeutig
b) Der 2011er Prozessor mit AVX ist ganz sicher nicht Bobcat ...

Das einzige wo es sich jetzt noch zu spekulieren lohnte, wäre die Frage nach nen Prozessoren in 2011: Llano, Bulldozer oder beide *chatt*

Aber das ist für mich eindeutig, das lohnt ebenfalls nicht. Nachdem AVX nur eine Art SSE5 mit 256bit ist, erübrigt sich das recht schnell

Edit:

Dr@ schrieb:
Der Autor hat auch drauf geantwortet.

Jo, und er kann nichtmal die Forenname richtig zuordnen, der Agner Fog arbeitet nicht für AMD *chatt*

ciao

Alex

rkinet · 13.02.2010

Opteron schrieb:
a) "Adoption" ist eindeutig
b) Der 2011er Prozessor mit AVX ist ganz sicher nicht Bobcat ...

Das einzige wo es sich jetzt noch zu spekulieren lohnte, wäre die Frage nach nen Prozessoren in 2011: Llano, Bulldozer oder beide

Zustimmung bei Bulldozer UND AVX.

Wobei aber LIano / K10.5 mit AVX doch technisch unrealistisch erscheint.
Und etwa andere SSE-Verschaltung müßte da auch entstehen was aber die DIE-Shot nicht hergeben.
Bliebe für den Liano also nur der alte & weitgehend unveränderte K10.5 Core übrig. Nur noch interessant ob AMD für die GPU bereits flexibel programmierbare Units verwendet und nicht nur ein Shrink von R830 u.ä. ?!

Opteron · 13.02.2010

rkinet schrieb:
Wobei aber LIano / K10.5 mit AVX doch technisch unrealistisch erscheint.

Ich schrieb ja, das erledigt sich schnell ..

OBrian · 13.02.2010

Opteron schrieb:
b) Der 2011er Prozessor mit AVX ist ganz sicher nicht Bobcat ...

Soll nicht Bobcat aus der gleichen Architektur wie Bulldozer gebaut sein, nur eben stark beschnitten? Warum sollte dann nicht auch AVX beherrscht werden? Wie schnell das wird, steht ja auf einem anderen Blatt. Aber da die Architektur sich eine Weile halten muß, wäre es ja wohl sinnvoll, das drinzulassen.

Dr@ · 13.02.2010

auf den Folien zum Bobcat stand explizit bis einschließlich SSE3 drauf. Womit alle späteren Erweiterungen ausgeschlossen sind. Und wer hat bitte irgendwann behauptet Bobcat hätte irgendwas mit BD zu tun? Das sind zwei völlig unterschiedliche Designs.

MfG @

Edit:

OBrian · 13.02.2010

Das hab ich mir ausgedacht, bin wohl einer Fehleinschätzung aufgesessen, weil die Kästchen auf der Folie so ähnlich angeordnet und beschriftet waren. Aber in so einer groben Grafik sieht wohl jede CPU ähnlich aus.

Opteron · 13.02.2010

OBrian schrieb:
Das hab ich mir ausgedacht, bin wohl einer Fehleinschätzung aufgesessen, weil die Kästchen auf der Folie so ähnlich angeordnet und beschriftet waren. Aber in so einer groben Grafik sieht wohl jede CPU ähnlich aus.

Jupp, so siehts aus.

Dresdenboy hat sogar ein Patent gefunden, das nur 32bit Pipelines beschreibt ... naja für ein Mobilcore mit UVD Einheit in der eingebauten GPU reichts sicherlich.

Wan_Mateng · 14.02.2010

Zum Thema Spekulation weil man das ja mit dem neuen Sockel schon angesprochen hat.
Diesbezüglich habe ich folgendes noch gefunden.

bzw. auch noch ganz interessant

http://translate.google.com/translate?hl=en&sl=ja&u=http://northwood.blog60.fc2.com/blog-entry-3318.html&ei=aC9XS6fEOYmo8Aay5-HGAw&sa=X&oi=translate&ct=result&resnum=3&ved=0CBIQ7gEwAjgK&prev=/search%3Fq%3Dintel%2Bpatsburg%2Bsandy%2Bbridge%26hl%3Den%26safe%3Doff%26sa%3DN%26start%3D10

Mal schauen was am Ende raus kommt. Bis jetzt sind wir ja immer nur vom "kleinen Sandy Bridge"ausgegangen während vom größeren gewisse Informationen noch verdeckt sind.

mfg

Twodee · 14.02.2010

Ähm Gulftown 6Core/8Threads ?? Fehler in der Folie?

Opteron · 14.02.2010

Twodee schrieb:
Ähm Gulftown 6Core/8Threads ?? Fehler in der Folie?

Klar was sonst ...

Twodee · 14.02.2010

...hätte ja sein können *buck*

rkinet · 14.02.2010

Wan_Mateng schrieb:
Mal schauen was am Ende raus kommt. Bis jetzt sind wir ja immer nur vom "kleinen Sandy Bridge"ausgegangen während vom größeren gewisse Informationen noch verdeckt sind.

Intel spart sich bei den Modell mit iGP Cache und Cores.

Bei den Okta-Cores hingegen wird das nachgereicht.

Interessant wie Intel weiterhin mit einem Basisdesign die ganze Bandbreite bei Server/Desktop/Notebook abdecken kann.

Opteron · 14.02.2010

rkinet schrieb:
Interessant wie Intel weiterhin mit einem Basisdesign die ganze Bandbreite bei Server/Desktop/Notebook abdecken kann.

Ich würde da eher ersteinmal will anstatt kann schreiben

Mittelfristig sehe ich AMD im Vorteil, Intels DIE ist langsam richtig gigantisch, im Desktop-Server natürlich topp, aber das braucht man in normalen Notebooks nicht. Stromspartechnisch kann mans mit clock-gating gut bekämpfen, aber das DIE bleibt groß. Aber naja das sind bei Intel wohl eher Peanuts

Twodee · 14.02.2010

Wie groß ist ein i3 bzw. i5 Die? Wie groß ist ein vergleichbarer (leistung) X2 bzw. X4 Mobile Die?

Opteron · 14.02.2010

Twodee schrieb:
Wie groß ist ein vergleichbarer (leistung) X2 bzw. X4 Mobile Die?

Was weiss ich, die Fusion DIE Größen sind noch nicht bekannt.
Aktuelle Chips meine ich nicht, ich rede ja von "mittelfristig", das ist nicht jetzt, dass ist in der Zukunft

Ontario könnte da ein heißes Eisen werden, dank OoO muss das Teil schneller als Atom werden, Videodecoding per GPU/Chipsatz und auch noch (wenn auch schlechte) OpenCL Beschleunigung, falls das mal eine weitere Verbreitung finden sollte.
Für ein Notebook (nicht nur Netbook) sollte das eigentlich schon reichen.

ciao

Alex

Twodee · 15.02.2010

Was nützt dann dieser Vergleich? Die Kongurenten des i3 / i5 sind doch nicht vor 2011 zu erwarten? Bis dahin bleibt Intel doch nicht etwa stehen?

Opteron · 15.02.2010

Twodee schrieb:
Was nützt dann dieser Vergleich? Die Kongurenten des i3 / i5 sind doch nicht vor 2011 zu erwarten? Bis dahin bleibt Intel doch nicht etwa stehen?

Na es ging ja nur um die Die Größe. Das was von Intel bis 2011 kommt ist Sandy Bridge (darum gehts ja hier im Thread ^^), und der wird garantiert nicht kleiner ... AVX z.B. braucht im Notebook auch keiner

Aber vielleich bleibt da erstmal Clarkdale alleine auf weiter Flur. Der doppel DIE Ansatz sollte auch einigermaßen billig sein.

ciao

Alex

Intel Sandy Bridge

Redaktion☆☆☆☆☆☆

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Moderation MBDB, ,

Grand Admiral Special

Moderation MBDB, ,

Redaktion☆☆☆☆☆☆

Admiral Special

Lord of the Stats, Special, ,

Redaktion☆☆☆☆☆☆

Lord of the Stats, Special, ,

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Lord of the Stats, Special, ,

Redaktion☆☆☆☆☆☆

Lord of the Stats, Special, ,

Redaktion☆☆☆☆☆☆

Ähnliche Themen

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆