AMDs Bulldozer bzw. was kommt nach dem K10

[Opteron]

Der SMT (Simultaneous Multithreading) Laberthread

Damit hier mal wieder Sinnvolles steht, aktualisiere ich mal die einjährige Spekulation:

Ein letztes noch zum BD-Kern als solches: Man munkelt, er soll ebenfalls SMT mitbringen.

Aktuelles "Gemunkel" aufgrund diverser AMD Patentschemata:

Zwei 2-issue INT Piplines für 2 Threads, die sich per "reverse Hyperthreading" auf 1x4-issue für einen Thread bündeln lassen. Quasi SMT for real men

Dazu L0 / Trace Cache zur bessren Sprungvorhersage und Loop-Detektor.

FPU wird wohl gleichbleiben, von SSE5 mal abgesehen.

ciao

Alex

 

[Undertaker 1]

War man sich nicht einig, das reverse SMT eigentlich nicht realisierbar ist? Wie sollen abhängige Operationen intern denn auch parallelisiert werden? Irgendwie konnte das im Zusammenhang mit diesem Gerücht noch nie erläutert werden, imho bleibt soetwas erstmal Voodoo... Aber ich lasse mich gerne eines besseren belehren

 

[Opteron]

War man sich nicht einig, das reverse SMT eigentlich nicht realisierbar ist? Wie sollen abhängige Operationen intern denn auch parallelisiert werden? Irgendwie konnte das im Zusammenhang mit diesem Gerücht noch nie erläutert werden, imho bleibt soetwas erstmal Voodoo... Aber ich lasse mich gerne eines besseren belehren

Ich weiss nicht wann Du da mit wem einig warst, aber die zugehörigen Patente sind schon so alt wie das Gerücht selbst also ~6 Jahre:

Das ist alles andre als Voodoo, das ist patentiert ;-)
http://www.patent2pdf.com/pdf/06574725.pdf

ciao

Alex

 

[Undertaker 1]

Ähm Moment, das ist aber etwas anderes als von dir beschrieben sowie "reverse Hyperthreading" benannt Hier geht es um die spekulative Ausführung möglicherweise anstehender Berechnungen im Voraus auf unausgelasteten Recheneinheiten, nicht um die Problematik, das manche Berechnungen eben schlicht und einfach nicht parallelisierbar sind. Das wäre "reverse Hyperthreading" und existiert nur als Aprilscherz:

http://www.ngohq.com/news/15678-reverse-hyperthreading-wrapper-v0-1-a.html

 

[Opteron]

Les mal genau, nicht nur die Überschrift
Von Deinem Link hab ich noch nie zuvor was gehört ;-)
Den Ausdruck "reverse HT" gibts schon ne halbe Ewigkeit, nicht nur seit letztem 1. April.

 

[Undertaker 1]

Ist eben auch nur ein Aprilscherz, da meines Wissens nicht realisierbar.

Mal anders gefragt: Wie definierst du "reverse HT/SMT"? Ich definiere damit, dass ein Thread auf mehreren Kernen parallel abgearbeitet wird. Ist die Beschränkung des Programms auf einen Thread zwangsläufig, da innerhalb von diesem Abhängigkeiten bestehen, besteht keine Möglichkeit der Parallelisierung. Aber das steht auch nicht in deinem Patent-PDF. Sonst zitiere aus diesem Mal die Stelle, auf welche du anspielen möchtest.

Echtes SMT könnte Bulldozer durchaus bieten.

 

[Mondrial]

Du hast es doch schon recht gut übersetzt...

Hier geht es um die spekulative Ausführung möglicherweise anstehender Berechnungen im Voraus auf unausgelasteten Recheneinheiten

Von ungenutzten Recheneinheiten sollen spekulativ Berechnungen ausgeführt werden, deren Ergebnisse der Thread vielleicht benötigen könnte. Inwieweit realisierbar sein und was es bringen könnte...wer weiß...

 

[X909]

Diese spekulative Ausführung auf freien Rechenkapazitäten erinnert mich an den Scheduler der Netburst CPUs. Die ALUs wurden immer voll ausgelastet, auch wenn die Bedingungen für eine Operation noch nicht erfüllt waren. Das hatte auch den Vorteil, dass die skalare Performance (Single-Thread) verbessert werden konnte (ansonsten wäre die IPC-Rate noch schlechter gewesen).

Der Nachteil bei sowas ist die Energieverschwendung wenn die Vorhersage der spekulativen Operanden bzw. des Thread-Verlaufs falsch sind. Denn dann wurde umsonst spekulativ gerechnet. Beim P4 gabs dafür das Replay. Dazu gibts irgendwo im Netz nen guten Artikel.

Zwei 2-issue INT Piplines für 2 Threads, die sich per "reverse Hyperthreading" auf 1x4-issue für einen Thread bündeln lassen. Quasi SMT for real men

Das finde ich nicht so interessant. Haben doch aktuelle CPUs auch schon.

i7 und Core2 sind 4x skalar, P4 und AMDs ab K8 3x skalar. Die Scheduler müssten je 3-issue sein, außer beim P4 mit seinem ungewöhnlichen Konzept und dem i7.

Nehalem hat 4 Pipelines die 4x1, 3x1 + 1x1 oder 2x2 genutzt werden können.

 

[Opteron]

i7 und Core2 sind 4x skalar, P4 und AMDs ab K8 3x skalar. Die Scheduler müssten je 3-issue sein, außer beim P4 mit seinem ungewöhnlichen Konzept und dem i7.

Uhh, bitte vorsichtig mit dem "skalar" Ausdruck, bleib bei "issue". Bei Skalar stellt sich jeder was andres vor, "issue" bezieht sich nur auf die Decoder.

Nehalem hat 4 Pipelines die 4x1, 3x1 + 1x1 oder 2x2 genutzt werden können.

Öhm .. Link ?
Ist mir so noch nicht bekannt. Das Ding hat SMT und kann damit nen 2ten Thread auf die Alus loslassen, ja. Prinzipiell kannst Du damit sogar behaupten, dass der Nehalem 2x4issue ist. Aber gleich nach dem Dekodiern wirds schon eng, da sind dann plötzlich nicht 4 Alus ... sondern nur 3 verfügbare INT Ports:
http://www.realworldtech.com/page.cfm?ArticleID=RWT040208182719&p=6

Die sind dann jeweils nochmals unterteilt, aber pro Takt kann man nur jeweils eine µOP an einen Port schicken.

@undertaker, les im pdf S12, den letzten Absatz, der geht dann auf der gleichen Seite noch 2 Zeilen in der nächsten Zeile weiter. Es folgt die Summary of the Invention, die besagt, dass man die beschriebenen Probleme löst.
(ich würde es gerne copy&pasten, aber geht leider nicht)

ciao

Alex

 

[Undertaker 1]

@undertaker, les im pdf S12, den letzten Absatz, der geht dann auf der gleichen Seite noch 2 Zeilen in der nächsten Zeile weiter. Es folgt die Summary of the Invention, die besagt, dass man die beschriebenen Probleme löst.
(ich würde es gerne copy&pasten, aber geht leider nicht)

Du hast es doch schon recht gut übersetzt...

Von ungenutzten Recheneinheiten sollen spekulativ Berechnungen ausgeführt werden, deren Ergebnisse der Thread vielleicht benötigen könnte. Inwieweit realisierbar sein und was es bringen könnte...wer weiß...

Jop, soetwas sollte durchaus Sinn machen. Ich finde aber die Bezeichnung "reverse Hyperthreading" dafür unpassend, denn das wäre der heilige Gral eines Designs: Eine Berechnung a+b=c und c+d=e zu parallelisieren. Das kann eben einfach nicht gehen, darum sollte diese Begrifflichkeit auch Scherzprogrammen wie dem oben verlinkten vorbehalten bleiben. Auch AMD hat diese Bezeichnung nirgends verwendet, oder hab ich da etwas übersehen?

 

[Opteron]

Auch AMD hat diese Bezeichnung nirgends verwendet, oder hab ich da etwas übersehen?

Nö, wenn ich mich recht erinnere, dann kam das um 2004 auf ner franz. Seite auf. Naja, wie wollen wirs dann nennen ?

In gewisser Weise stimmt schon, in dem pdf steht ja, das kleine, parallele Codeschnipsel nicht per OS erkannt werden können. Die erkennt dann halt die AMD Thread Logik. Wie besagt, parallele Codeschnipsel ... keine seriellen, wie in Deinem Beispiel. Das geht natürlich nicht. Das wäre kein heiliger Gral, das ist das Perpetuum Mobile ;-)

ciao

Alex

 

[Undertaker 1]

Der Optimalfall wäre ja, das ein Programm mit parallel abarbeitbaren Codeteilen diese schon beim Programmentwurf auf mehrere Threads verteilt. Im Grund wäre diese Implementierung also eine Möglichkeit, Softwareunzulänglichkeiten auszubügeln.

 

[Opteron]

Der Optimalfall wäre ja, das ein Programm mit parallel abarbeitbaren Codeteilen diese schon beim Programmentwurf auf mehrere Threads verteilt. Im Grund wäre diese Implementierung also eine Möglichkeit, Softwareunzulänglichkeiten auszubügeln.

Ne, das ist ja das, was die AMD Leute im Patent pdf schreiben, das rentiert sich nicht, der Verwaltungsaufwand für jeden kleinen Codeschnippsel ist dafür zu groß. In Hardware gegossen macht es (anscheinend ^^) mehr Sinn ;-)

Auf alle Fälle fällt das ganze Thread-Sync Gedöns in der Software weg, und die Hardware wird das (hoffentlich) viel besser und schneller können.

Die werden schon wissen, für was es gut ist

ciao

Alex

 

[X909]

Uhh, bitte vorsichtig mit dem "skalar" Ausdruck, bleib bei "issue". Bei Skalar stellt sich jeder was andres vor, "issue" bezieht sich nur auf die Decoder.
Alex

Nicht Dekoder sondern Scheduler. Das ist wichtig für das folgende:

Öhm .. Link ?
Ist mir so noch nicht bekannt. Das Ding hat SMT und kann damit nen 2ten Thread auf die Alus loslassen, ja. Prinzipiell kannst Du damit sogar behaupten, dass der Nehalem 2x4issue ist. Aber gleich nach dem Dekodiern wirds schon eng, da sind dann plötzlich nicht 4 Alus ... sondern nur 3 verfügbare INT Ports:
http://www.realworldtech.com/page.cfm?ArticleID=RWT040208182719&p=6

Die sind dann jeweils nochmals unterteilt, aber pro Takt kann man nur jeweils eine µOP an einen Port schicken.

Alex

Hinterm Dekoder gehts beim i7 wie gesagt 4x skalar weiter, das sieht man in der von Dir verlinkten Grafik auch an der Kennzeichnung (4µOps) vorm reorder buffer.

Der Scheduler hat beim i7 nicht 3, nicht 4 sondern 6 Ports. In der verlinkten Grafik fehlen die Ports 2, 3 und 4. Vermutlich weil keine ALUs dranhängen sondern AGUs.

Dazu kommt noch, µOp-Fusion, womit man mehrere µOps durch einen Pfad bekommt.

Ich will hier aber keine Diskusion lostreten, da die Ausführungseinheiten sowieso bei keiner aktuellen CPU limitieren. Den eine 4x skalare CPU mit 6 issues bekommt real keine 3 IPCs hin. Da würde auch ein breiteres Back-End nicht helfen.

Ich meinte nur, dass das Konzept die Pipelines flexibel aufzuteilen, nichts neues ist. Das hatte der P4 schon.

Der Optimalfall wäre ja, das ein Programm mit parallel abarbeitbaren Codeteilen diese schon beim Programmentwurf auf mehrere Threads verteilt.

In dem Zusammenhang gibts genau das schon: EPIC

 

[Opteron]

Vorweg erstmal:
Hast Du ne brauchbare Definition von Superskalar gefunden ?
Ich nicht, deswegen die Frage ...

Ich hab mal ein paar Stunden gegoogelt, Fazit war, dass das aus der Risc Abteilung kam und sich auch nur auf INT ALUs/Einheiten bezieht. Das ist dann bei x86 Chips 2x Käse, da es

a) Nach dem Dekoder keine "x86 Ops" mehr gibt, sondern µOps. Bei Risc Chips wird das aber nicht unterschieden

b) Da es nur die Int Einheiten betrifft, eben die AGUs wegfallen ... die sind zwar da, und machen auch was, aber nachdem was ich gefunden hab, ist das egal, die rechnen nichts, das sind nur sekundär FUs.

Beim K7/K8/K9 wird das ganze noch lustiger, die haben zusammen mit den FPUs Piplines 9 Ports, da sie nicht wie bei Intel unterteilt an einem Port hängen, sondern direkt an der Reservation Station. Also wenn Du das mit einbeziehst, könnte man sagen, dass die AMDs an der Stelle 9fach superskalar wären

Summa Summarum .. ich mag den Ausdruck nicht mehr, zu schwammig. Ausser Du hast ne gute Definition aus verlässlicher Quelle.

Fusion hat AMD teilweise übrigens auch, die schippern da in Ihrem MacroOps auch Adressen + Befehle in einem durchs Rechenwerk, seit dem K7 ;-)
µOP Fusion ist nichts andres.
Nur das Fusionieren mehrerer JMP+XY Befehle (MacroOP Fusion) können sie nicht.

Die µOpFusion ist bei Intel nicht wirklich elegant. Erst zerlegt der Decoder die CISC Befehle in µOps, nur dass die dann hinterher wieder zusammengekleistert werden können. Dann lieber AMDs Ansatz ;-)
Aber gut, die Leistung gibt ersteinmal Intel recht Wichtig ist was hinten rauskommt ^^

Ich meinte nur, dass das Konzept die Pipelines flexibel aufzuteilen, nichts neues ist. Das hatte der P4 schon.

Gibts das nicht schon seit dem PentiumPro ?
Das neue an dem Ansatz ist, dass man die 4issue Pipline auch mit 2 Threads belegen kann, das kann der P4 nicht, nur indirekt wenn Du Dich auf die neueren Modelle mit Hyperthreading beziehst.

Unterschied ist jetzt der, dass bei AMD keine Leistung verloren geht, da sich die beiden Threads nicht in die Quere kommen, da jeder seine fest zugeodrnete Pipline hat. Mit SMT gibts dagegen Behinderungen, die die single-thread Leistung beeinträchtigen.

ciao

Alex

 

[Undertaker 1]

In dem Zusammenhang gibts genau das schon: EPIC

Wie meinen? Wäre das immer der Fall, hätte die Implementierung keinen Sinn. Ist wohl wie Opteron sagt einfach zu aufwendig oder nicht immer am effizientesten.

 

[Opteron]

Wie meinen? Wäre das immer der Fall, hätte die Implementierung keinen Sinn. Ist wohl wie Opteron sagt einfach zu aufwendig oder nicht immer am effizientesten.

Naja, der Compiler versucht bei EPIC halt sein Bestes

Aber an ne Hardwarelösung dürfte das dann auch nicht rankommen. Wobei es aber ja noch keine Hardwarelösung gibt

ciao

Alex

 

[X909]

Vorweg erstmal:
Hast Du ne brauchbare Definition von Superskalar gefunden ?
Ich nicht, deswegen die Frage ...

Ich hab mal ein paar Stunden gegoogelt, Fazit war, dass das aus der Risc Abteilung kam und sich auch nur auf INT ALUs/Einheiten bezieht. Das ist dann bei x86 Chips 2x Käse, da es

a) Nach dem Dekoder keine "x86 Ops" mehr gibt, sondern µOps. Bei Risc Chips wird das aber nicht unterschieden

Ok, streichen wir die Begriffe und halten konkret fest, dass Nehalem und vermutlich Bulldozer bis zum Scheduler 4µOps parallel verarbeiten. O.K.?

Im Zusammenhang mit Fusion u.s.w. wird auch deutlich, dass diese Angaben mit Vorsicht zu genießen sind. Wie Du schon sagtest, nach dem Decoder gibts keine x86-Ops mehr (sondern nach herrschender Definition RISC-Instruktionen ).

Da Intel µOps und AMD µOps nicht identisch sind, ist also keine Vergleichbarkeit gegeben.

b) Da es nur die Int Einheiten betrifft, eben die AGUs wegfallen ... die sind zwar da, und machen auch was, aber nachdem was ich gefunden hab, ist das egal, die rechnen nichts, das sind nur sekundär FUs.

Die sind nicht mal so nebenbei in nem Prozessor AGUs sind genauso wichtig wie ALUs, denn die berechnen die Adressen zum Laden und Speichern. Wenn die Ports sowohl von ALUs als auch AGUs genutzt werden, kann man davon ausgehen, dass etwa 30-50% für AGU genutzt wird, der Rest für ALU - denn keine CPU kann ohne Werte (sinnvoll) rechnen

Beim K7/K8/K9 wird das ganze noch lustiger, die haben zusammen mit den FPUs Piplines 9 Ports, da sie nicht wie bei Intel unterteilt an einem Port hängen, sondern direkt an der Reservation Station. Also wenn Du das mit einbeziehst, könnte man sagen, dass die AMDs an der Stelle 9fach superskalar wären

FPU und Int kommen sich üblicherweise nicht wirklich in die Quere, daher sind die Ports auch shared.

Ab ich denke sowohl Intel als auch AMD haben ihre Gründe. Wie bereits erwähnt, die Breite am Backend ist nie zu knapp bei aktuellen CPUs.

Die µOpFusion ist bei Intel nicht wirklich elegant. Erst zerlegt der Decoder die CISC Befehle in µOps, nur dass die dann hinterher wieder zusammengekleistert werden können. Dann lieber AMDs Ansatz ;-)
Aber gut, die Leistung gibt ersteinmal Intel recht Wichtig ist was hinten rauskommt ^^

Naja, wenn mann mehrere Befehle in einem Zyklus ausführen kann, während man ansonsten mehrere Zyklen bräuchte, ist das alles andere als unelegant.

Gibts das nicht schon seit dem PentiumPro ?
Das neue an dem Ansatz ist, dass man die 4issue Pipline auch mit 2 Threads belegen kann, das kann der P4 nicht, nur indirekt wenn Du Dich auf die neueren Modelle mit Hyperthreading beziehst.
Alex

Genau das meinte ich. Der P4 konnte das schon, denn ohne würde SMT keinen Sinn machen.

Unterschied ist jetzt der, dass bei AMD keine Leistung verloren geht, da sich die beiden Threads nicht in die Quere kommen, da jeder seine fest zugeodrnete Pipline hat. Mit SMT gibts dagegen Behinderungen, die die single-thread Leistung beeinträchtigen.

ciao

Alex

Wenn man für SMT Ressourcen fest zuordnet ist das nicht vorteilhaft sondern nachteilig! Daher gibt es feste Aufteilungen nur dann, wenn alles andere nicht möglich oder zu aufwendig ist.

Der Sinn von SMT ist doch, freie Ressourcen zu nutzen. Je flexibler die Aufteilung ist, desto besser funktioniert das.

Bei HT kommt sich in der Pipeline nix in die Quere. Der Scheduler gibt dem Thread die Ressourcen, der sie benötigt.

Es wäre doch schade, wenn Thread A auf Daten ausm L2 wartet und Thread B nur 2 Ports nutzen kann, weil die anderen 2 für Thread A reserviert sind obwohl der still steht.

Ich glaube auch nicht, dass AMD das so fest aufteilen wird, außer man will sich die Logik für die dynamische Verteilung im Scheduler sparen.

Wie meinen? Wäre das immer der Fall, hätte die Implementierung keinen Sinn. Ist wohl wie Opteron sagt einfach zu aufwendig oder nicht immer am effizientesten.

Bei EPIC wird parallelisierbarer Code innerhalb eines Threads vom Compiler als parallel Ausführbar gekennzeichnet. Die CPU spart sich die Out-of-Order Logik und kann mehrere Funktionseinheiten parallel füttern.

Da das auch Nachteile (komplexe Compiler und großen Code) hat, konnte es sich nicht (für Desktop) durchsetzen. Sh. Itanium.

 

[Opteron]

Ok, streichen wir die Begriffe und halten konkret fest, dass Nehalem und vermutlich Bulldozer bis zum Scheduler 4µOps parallel verarbeiten. O.K.?

Klar

Im Zusammenhang mit Fusion u.s.w. wird auch deutlich, dass diese Angaben mit Vorsicht zu genießen sind. Wie Du schon sagtest, nach dem Decoder gibts keine x86-Ops mehr (sondern nach herrschender Definition RISC-Instruktionen ).

Da Intel µOps und AMD µOps nicht identisch sind, ist also keine Vergleichbarkeit gegeben.

Jo das ist ein tolles Wirrwarr ;-)

Die sind nicht mal so nebenbei in nem Prozessor AGUs sind genauso wichtig wie ALUs, denn die berechnen die Adressen zum Laden und Speichern. Wenn die Ports sowohl von ALUs als auch AGUs genutzt werden, kann man davon ausgehen, dass etwa 30-50% für AGU genutzt wird, der Rest für ALU - denn keine CPU kann ohne Werte (sinnvoll) rechnen

Lol, ne so meinte ich das nicht. Klar erfüllen die nen Zweck, aber halt sekundär, nicht primär.

FPU und Int kommen sich üblicherweise nicht wirklich in die Quere, daher sind die Ports auch shared.

Ah ok, wusste ich noch nicht
Was sagst Du zu einer FPU Einheit, die von 2 Threads geteilt werden ?
Naja ist eigentlich in dem Fall das gleiche wie bei SMT. Solange die Buffer groß genug sind .. reichts.

Ab ich denke sowohl Intel als auch AMD haben ihre Gründe. Wie bereits erwähnt, die Breite am Backend ist nie zu knapp bei aktuellen CPUs.

Jupp. Bei AMD gefällt mir halt die ALU/AGU Kombination. Deswegen können die µOP Fusion schon im Dekoder machen, und nicht wie bei Intel zuerst aufteilen und dann wieder fusionieren. Aber naja wird alles halt seine Trade-Offs haben.

Naja, wenn mann mehrere Befehle in einem Zyklus ausführen kann, während man ansonsten mehrere Zyklen bräuchte, ist das alles andere als unelegant.

Jo aber die Befehle wurden eine Stufe vorher erst getrennt

Wenn man für SMT Ressourcen fest zuordnet ist das nicht vorteilhaft sondern nachteilig! Daher gibt es feste Aufteilungen nur dann, wenn alles andere nicht möglich oder zu aufwendig ist.

Jein, die Leistung eines einzelnen Threads leidet ein bisschen drunter.

Der Sinn von SMT ist doch, freie Ressourcen zu nutzen. Je flexibler die Aufteilung ist, desto besser funktioniert das.

Jupp, aber AMD will anscheinend 2 Threads ohne negative Auswirkungen in einem Kern unterbringen.

Bei HT kommt sich in der Pipeline nix in die Quere. Der Scheduler gibt dem Thread die Ressourcen, der sie benötigt.

Naja überleg mal, mit 2 Threads kommen milchmädchenhaft gerechnet doppelt soviel µOps in die Puffer. Klar, die max. Breite sind 4 µOps, aber im Mittel werden die jetzt sicher nicht 100% ausgenützt, ansonsten bräuchte man auch kein SMT

Wenn jetzt die ganzen µOps in die Reservation Station fallen, und die gut belegt ist, dann dauert es länger, bis sie an die ALUs/FPU verteilt werden.

Ist ja das Credo von SMT, single Thread Performance opfern, dafür aber den Rechendurchsatz steigern. Nimm z.B. 2 Boinc Work Units. 2 Stück sind da nicht schneller fertig als eine Einzelne. Die einzelne ist schneller berechnet. Aber nach weniger als der doppelten Zeit habe ich mit SMT dafür halt 2 WUs berechnet.

Es wäre doch schade, wenn Thread A auf Daten ausm L2 wartet und Thread B nur 2 Ports nutzen kann, weil die anderen 2 für Thread A reserviert sind obwohl der still steht.

Jo das ist nicht optimal, ist halt der Nachteil, wenn man auf single-thread Leistung optimiert. AMD wird das kleinhalten indem man:
a) Mit 2 D-Caches plant
b) Den 2x2issue Modus nur benützt, wenn es auch was paralleles zu tun gibt, in dem Fall sollte das dann auch der optimale Betriebsmodus sein, ansonsten laufen die beiden Piplines ja gebündelt als eine 4issue Pipeline.

Ich glaube auch nicht, dass AMD das so fest aufteilen wird, außer man will sich die Logik für die dynamische Verteilung im Scheduler sparen.

Ja ich spekulier auch nur
2011 (oder mit Glück 2010, wenn die Opterons früher kommen) sind wir schlauer ;-)

Da das auch Nachteile (komplexe Compiler und großen Code) hat, konnte es sich nicht (für Desktop) durchsetzen. Sh. Itanium.

Wieso, das hat sich doch durchgesetzt ... zähl mal die ganzen ATi Grafikkarten
Mit AMDs Fusion Chips wandert dass dann sogar in die CPU

Ich finde das Konzept prima, auf single-thread getunte x86 Cores + ein paar Hundert VLIW Kernchen für die parallelen Arbeiten ;-)

Wenn man dann seinen Code mit APIs wie RapidMind programmiert ist auch das Entwickeln dafür einfach

1. First, convert the numerical types used in the kernel to the equivalent RapidMind types.
2. Second, create a RapidMind program object.
3. Third, apply the program object to an array of data which will invoke a parallel computation which will be coordinated by the platform's runtime execution manager.

http://www.ibm.com/developerworks/library/pa-rapidmind/
http://www.rapidmind.net

ciao

Alex

 

[X909]

Na dann sind wir uns ja größtenteils einig

Falls AMD 2 D-Caches auf unterster Ebene einsetzt und sowohl Assoziativität, Größe, Anbindung und Latenz nicht darunter leiden, wäre das sicher ein ordentlicher Vorteil für SMT.

Was die Scheduler-Ports angeht bleibe ich aber dabei, je flexibler desto besser. Warten wir mal ab was kommt, ich prophezeie, dass AMD keine feste Aufteilung der Ports/ALUs unter den Threads vornehmen wird.

Das was mit GPGPU gemacht wird geht in die Richtung extremes Multithreading. EPIC nutzt jedoch "programmierte" Parallelität innerhalb nur eiens Threads. Daher würde ich das nicht vergleichen. Aber das ist sicher Auslegungssache... Man kann sich ja auch lange streiten, wo die Grenze zwischen RISC und CISC liegt.

Ich bin jedenfalls enorm gespannt, was die Entwicklung so bringt. Sowohl Intel als auch AMD werden wohl 256 Bit SIMD bringen und damit die rechnerischen FLOPS auf einen Schlag verdoppeln. Man wehrt sich halt gegen GPGPU

 

[Opteron]

Na dann sind wir uns ja größtenteils einig

Jupp

Falls AMD 2 D-Caches auf unterster Ebene einsetzt und sowohl Assoziativität, Größe, Anbindung und Latenz nicht darunter leiden, wäre das sicher ein ordentlicher Vorteil für SMT.

Was die Caches für Charakteristika haben, weiss man nicht, aber auf alle Fälle sinds L1 Caches, siehe Fig.5:
http://www.patent2pdf.com/pdf/20080263373.pdf

Was die Scheduler-Ports angeht bleibe ich aber dabei, je flexibler desto besser. Warten wir mal ab was kommt, ich prophezeie, dass AMD keine feste Aufteilung der Ports/ALUs unter den Threads vornehmen wird.

Siehe Fig.5
Was aber natürlich nicht heißen muss, dass die Patent Architektur auch so kommt.

Das was mit GPGPU gemacht wird geht in die Richtung extremes Multithreading. EPIC nutzt jedoch "programmierte" Parallelität innerhalb nur eiens Threads. Daher würde ich das nicht vergleichen. Aber das ist sicher Auslegungssache... Man kann sich ja auch lange streiten, wo die Grenze zwischen RISC und CISC liegt.

Ja ne, jetzt schmeißst Du die ATi und nVidia GPUs in einen Topf
Hatte explizit die ATis angesprochen, da die auf einem VLIW Konzept basieren. Epic ist nichts andres, nur der Name von Intels VLIW Architektur.
nV ist wiederum kein VLIW.

Ich bin jedenfalls enorm gespannt, was die Entwicklung so bringt. Sowohl Intel als auch AMD werden wohl 256 Bit SIMD bringen und damit die rechnerischen FLOPS auf einen Schlag verdoppeln. Man wehrt sich halt gegen GPGPU

Jupp, mal schauen, was wir 2011 dann so im Laden haben, spannend ist es allemal

ciao

Alex

 

[mr.dude]

Wie gesagt, die offizielle Roadmap spricht (noch?) von 2010 - aber Änderungen muss man natürlich abwarten, wenn Bulldozer jetzt auf 2011 verschoben wurde, könnten sich hier auch Verschiebungen ergeben - es widerstrebt mir nur, dass du hier spekulative Ansichten als Fakt darstellst, wie gesagt: Begriffe wie Fahrplan sind mit Roadmap zu assoziieren, und die sagt 2010. So die Sachlage, und nun btt

Na ja, Intel Roadmaps kannst du nicht ernst nehmen. Wenn die Jahr X schreiben, dann wird es in Wirklichkeit Jahr X+1. Du kannst dir ja die letzten Roadmaps mal anschauen, wie Penryn oder Nehalem. War genau so. Von "Prestige Modellen", die keine Relevanz für den Markt haben, mal abgesehen. Und das wird bei Westmere und Sandy Bridge nicht anders sein.
Übrigens, du solltest schon genauer lesen. Ich habe nirgendwo etwas als Fakt hingestellt.

Wie sollen abhängige Operationen intern denn auch parallelisiert werden?

Wer redet denn von abhängigen Operationen? Es geht ja erstmal nur um einen Code Stream (Single Thread). Abhängige Instruktionen werden letztendlich so gehandelt wie bei Instruction pipelining auch. Oder anders formuliert, sie sind weiterhin problematisch, weil nicht parallelisierbar.

Mal anders gefragt: Wie definierst du "reverse HT/SMT"? Ich definiere damit, dass ein Thread auf mehreren Kernen parallel abgearbeitet wird.

U.a. Wie man es letztendlich definiert, hängt einfach von der Konzeption der Architektur ab. Du könntest letztendlich auch alles in einem Kern unterbringen.

Ist die Beschränkung des Programms auf einen Thread zwangsläufig, da innerhalb von diesem Abhängigkeiten bestehen, besteht keine Möglichkeit der Parallelisierung.

Ach nein? Da dürfte 1 Decoder für Prozessoren doch ausreichen, oder?

Der Optimalfall wäre ja, das ein Programm mit parallel abarbeitbaren Codeteilen diese schon beim Programmentwurf auf mehrere Threads verteilt.

Das ist höchstens eine Möglichkeit der Optimierung, aber kein Optimalfall. Wie schon erwähnt wurde, jeder Thread bringt Overhead mit sich. Je mehr Threads, umso schlechter letztendlich die Effizienz. Der Optimalfall wäre, wenn EIN Thread sämtliche Ressourcen des Prozessors nutzen könnte. Und genau darum geht es ja bei Reverse SMT oder wie immer du es auch nennen willst.
Man sollte sich immer bewusst sein, Multi Threading wurde dafür konzipiert, dass mehrere verschiedene Aufgaben parallel abgearbeitet werden können. Dementsprechend hat sich auch die Hardware entwickelt. Da hier aber viele Ressourcen ungenutzt blieben, versucht man nun eine Aufgabe auf mehrere Threads zu verteilen. Und das ist letztendlich nicht mehr als suboptimaler Workaround. Das einzig positive daran ist, dass es recht effektiv bei gut parallelisierbaren Aufgaben ist. Zumindest was die Hardware betrifft. Siehe auch Many Core.
Es gibt im Bereich der Softwareentwicklung trotzdem viele serielle Algorithmen, auch in Zukunft. Insofern wird serielle Leistung weiterhin für Prozessoren eine wichtige Rolle spielen.

Ich finde das Konzept prima, auf single-thread getunte x86 Cores + ein paar Hundert VLIW Kernchen für die parallelen Arbeiten ;-)

Dito.

 

[Undertaker 1]

Du musst wohl auch auf alles eingehen, ob an dich gerichtet oder nicht?

Na ja, Intel Roadmaps kannst du nicht ernst nehmen. Wenn die Jahr X schreiben, dann wird es in Wirklichkeit Jahr X+1. Du kannst dir ja die letzten Roadmaps mal anschauen, wie Penryn oder Nehalem. War genau so. Von "Prestige Modellen", die keine Relevanz für den Markt haben, mal abgesehen. Und das wird bei Westmere und Sandy Bridge nicht anders sein.
Übrigens, du solltest schon genauer lesen. Ich habe nirgendwo etwas als Fakt hingestellt.

Nanu? Penryn 2007, Nehalem 2008, so stand es in den Tick-Tock Roadmpaps und so kam es. Das ist aber hier nicht das Thema, EoD.

Wer redet denn von abhängigen Operationen? Es geht ja erstmal nur um einen Code Stream (Single Thread). Abhängige Instruktionen werden letztendlich so gehandelt wie bei Instruction pipelining auch. Oder anders formuliert, sie sind weiterhin problematisch, weil nicht parallelisierbar.

Das habe ich auch bereits geschrieben - wenn die Unabhängigkeit sicher ist, kann man es gleich in mehrere Threads splitten. Dazu wiederum siehe die Ergänzung Operons.

U.a. Wie man es letztendlich definiert, hängt einfach von der Konzeption der Architektur ab. Du könntest letztendlich auch alles in einem Kern unterbringen.

Die Definition von SMT ist ja recht klar, da fällt die Umkehr nicht schwer und die Definition ist in meinen Augen absolut klar. Aber natürlich, nimmt man es genau muss man es erstmal exakt festlegen, für die AMD-Implementierung ist es zumindest imho ganz klar unpassend, und darum verwenden die diesen Begriff auch nicht.

Ach nein? Da dürfte 1 Decoder für Prozessoren doch ausreichen, oder?

Für solche Späße wie a+b=c b+c=d durchaus... Aber das das etwas irreal ist weißt du ja Nichtsdestotrotz, vieles bleibt eben nicht parallelisierbar.

Das ist höchstens eine Möglichkeit der Optimierung, aber kein Optimalfall. Wie schon erwähnt wurde, jeder Thread bringt Overhead mit sich. Je mehr Threads, umso schlechter letztendlich die Effizienz. Der Optimalfall wäre, wenn EIN Thread sämtliche Ressourcen des Prozessors nutzen könnte. Und genau darum geht es ja bei Reverse SMT oder wie immer du es auch nennen willst.
Man sollte sich immer bewusst sein, Multi Threading wurde dafür konzipiert, dass mehrere verschiedene Aufgaben parallel abgearbeitet werden können. Dementsprechend hat sich auch die Hardware entwickelt. Da hier aber viele Ressourcen ungenutzt blieben, versucht man nun eine Aufgabe auf mehrere Threads zu verteilen. Und das ist letztendlich nicht mehr als suboptimaler Workaround. Das einzig positive daran ist, dass es recht effektiv bei gut parallelisierbaren Aufgaben ist. Zumindest was die Hardware betrifft. Siehe auch Many Core.
Es gibt im Bereich der Softwareentwicklung trotzdem viele serielle Algorithmen, auch in Zukunft. Insofern wird serielle Leistung weiterhin für Prozessoren eine wichtige Rolle spielen.

Mit der softwareseitigen Threadaufteilung hat diese Implementierung nichts zu tun, diese kann sie nicht ersetzen. Eine spekulative Ausführung wie dort vorgesehen besitzt zwangsläufig diverse Einschränkungen, die sich von selbst verstehen, z.T. auch wirklich schwerwiegende Nachteile wie z.B. beim Punkt Energieverbrauch. Es bleibt essentiell, dass sicher parallelisierbare Aufgaben vorher bereits in Software in verschiedene Threads gegossen werden.


Ich denke, wir schweifen jetzt aber zu weit vom Thema ab.

 

[mr.dude]

Nanu? Penryn 2007, Nehalem 2008, so stand es in den Tick-Tock Roadmpaps und so kam es.

Eben nicht. Kannst du lesen? 2007 erschien spät EIN Modell, der QX9650. Dazu noch ein Schnellschuss im verbuggten C0 Stepping. Breite Verfügbarkeit war erst Q1/Q2 2008 gegeben. Bei Server Chips bin ich mir momentan nicht mal sicher. Ähnliches bei Nehalem. Core i7 ist nicht mehr als eine Notlösung, um überhaupt etwas auf dem Markt zu haben. Relevant ist das nicht. Aber schön wie Intel immer wieder Bauernfängerei betreibt und sowas noch als Enthusiasten Plattform verkauft. Nehalem Server 2009, Mainstream Desktop frühestens H2 2009, Notebooks vermutlich noch später. Und anders wird das in Zukunft auch nicht sein.

Wenn die Unabhängigkeit sicher ist, kann man es gleich in mehrere Threads splitten.

Erstens, wie willst du das machen? Wir sind schliesslich immer noch auf µOps Ebene. Und zweitens, das ist eben die schlechtere Option.

Die Definition von SMT ist ja recht klar, da fällt die Umkehr nicht schwer und die Definition ist in meinen Augen absolut klar. Aber natürlich, nimmt man es genau muss man es erstmal exakt festlegen, für die AMD-Implementierung ist es zumindest imho ganz klar unpassend, und darum verwenden die diesen Begriff auch nicht.

Nein. Der Begriff wird nicht verwendet, weil es ihn offiziell nicht gibt. Dafür müsste man ihn erstmal definieren.

Für solche Späße wie a+b=c b+c=d durchaus... Aber das das etwas irreal ist weißt du ja Nichtsdestotrotz, vieles bleibt eben nicht parallelisierbar.

Ganz im Gegenteil. Sehr vieles ist parallelisierbar. Übrigens auch eines der komplexesten Themen der Compiler Entwicklung überhaupt. Es gibt eben nicht nur "a+b=c b+c=d", sondern anschliessend auch noch "e+f=g f+g=h" usw. Letztendlich sind weit mehr µOps parallelisierbar als nicht.

Mit der softwareseitigen Threadaufteilung hat diese Implementierung nichts zu tun

Welche Implementierung denn? Wovon redest du eigentlich? Irgendwie recht konfus deine ganzen Aussagen.

Eine spekulative Ausführung wie dort vorgesehen besitzt zwangsläufig diverse Einschränkungen

Es geht hier nicht um spekulative Ausführung, sondern generell um µOps Parallelisierung. Ein guter Prefetcher bzw Scheduler bedingt dies zwar, hat damit aber nichts zu tun.

Es bleibt essentiell, dass sicher parallelisierbare Aufgaben vorher bereits in Software in verschiedene Threads gegossen werden.

Nein, eben nicht. Du musst immer zwischen Software- und Hardware-Threading differenzieren. Du denkst einfach in zu klassischen und leider auch ziemlich festgefahrenen Strukturen.

 

[Undertaker 1]

Eben nicht. Kannst du lesen? 2007 erschien spät EIN Modell, der QX9650. Dazu noch ein Schnellschuss im verbuggten C0 Stepping. Breite Verfügbarkeit war erst Q1/Q2 2008 gegeben. Bei Server Chips bin ich mir momentan nicht mal sicher. Ähnliches bei Nehalem. Core i7 ist nicht mehr als eine Notlösung, um überhaupt etwas auf dem Markt zu haben. Relevant ist das nicht. Aber schön wie Intel immer wieder Bauernfängerei betreibt und sowas noch als Enthusiasten Plattform verkauft. Nehalem Server 2009, Mainstream Desktop frühestens H2 2009, Notebooks vermutlich noch später. Und anders wird das in Zukunft auch nicht sein.

Bitte sachlich bleiben Ich definiere soetwas nicht über Modellzahlen, wo willst du da die Grenze ziehen? Beide Modelle waren 1-2 Monate vor Jahresende verfügbar.

Erstens, wie willst du das machen? Wir sind schliesslich immer noch auf µOps Ebene. Und zweitens, das ist eben die schlechtere Option.

Vorsicht, nicht in jedem Fall, hier musst du unterscheiden! Für viele Berechungen kann im Voraus bekannt sein, dass sie zu 100% unabhängig sind und hier macht es sehr viel mehr Sinn, diese auch fest in Threads zu unterteilen und das nicht zur Laufzeit entscheiden zu lassen. Und so wirds auch gemacht

Nein. Der Begriff wird nicht verwendet, weil es ihn offiziell nicht gibt. Dafür müsste man ihn erstmal definieren.

Eine Definition von SMT oder HT gibt es zur Genüge, die Bedeutung von "reverse" ist auch klar - da braucht man nicht zu diskutieren. Opteron hatte diesen Begriff anfänglich benutzt, daruf basierte die Diskussion wie du weiter oben finden kannst.

Ganz im Gegenteil. Sehr vieles ist parallelisierbar. Übrigens auch eines der komplexesten Themen der Compiler Entwicklung überhaupt. Es gibt eben nicht nur "a+b=c b+c=d", sondern anschliessend auch noch "e+f=g f+g=h" usw. Letztendlich sind weit mehr µOps parallelisierbar als nicht.

Das ist mir zu allgemein. Schon allein weil parallelisierbar eine weite Formulierung ist, kann ich zweifach, dreifgach, vierfach parallel rechnen? Ein gutes Beispiel wäre eine KI-Simulation, hier kannst du maximal so lange parallelisieren bis du auf zwangsläufige Interaktionen stößt, und da ist dann das Ende jeglicher Optimierungen in dieser Beziehung erreicht.

Welche Implementierung denn?

Siehe Opterons Posting weiter oben, wir reden von einer Umsetzung dieses Patentes:

http://www.patent2pdf.com/pdf/06574725.pdf

Es geht hier nicht um spekulative Ausführung

"speculatively executing threads", der erste Absatz im PDF.

Du musst immer zwischen Software- und Hardware-Threading differenzieren

Ich sprach wie zu lesen von der Aufteilung in Software als Grundstock. Dies jetzt in Hardware zu erweitern ist möglich und kann sinnvoll sein, aber den Softwareweg nicht in sinnvoller Weise vollkommen ersetzen.



Die "reverse SMT" (bis wir da einen treffenderen Namen haben) Diskussion sollte hier vielleicht besser ausgelagert werden.

 

[X909]

Parallelisierung innerhalb eines Threads ist nicht mit SMT zu vergleichen. Wenn man parallelisierbare Aufgaben in Threads aufteilen will, muss man bereits zum Compilierungszeitpunkt wissen, was parallel laufen kann. Das lohnt sich dann auch nicht für ein Paar Berechnungen. Da muss man schon ganze Programmteile parallel laufen lassen.

Die Parallelisierung auf µOp-Ebene wird ja nun schon seit dem Pentium Pro gemacht. Out-of-Order eben. Das funktioniert schon mit 2 Instruktionen, wofür es sich nie im Leben lohnen würde zwei Threads einzusetzen. Zumal diese Parallelisierungsmöglichkeit evtl. auch erst zur Laufzeit auftritt.

Hier wird auch allgemein der Fehler gemacht, immer von "klassischen" Berechnungen auszugehen. x86 Code besteht eben nicht nur aus a+b=c. So sehen nur ein Bruchteil der Befehle aus. Bereits auf Code-Ebene gibt es Sprünge, Moves u.s.w., die eine enorme Bedeutung haben.

Auf µCode Ebene kommen dann noch Load&Store dazu, die (wie oben beim Thema AGU bereits erwähnt) einen wichtigen Anteil an dem haben, was ein Rechenwerk so tut.

Das alles viel zu komplex um es so auf a+b=c reduziert darzustellen.

 

[mr.dude]

Bitte sachlich bleiben Ich definiere soetwas nicht über Modellzahlen, wo willst du da die Grenze ziehen?

Die Grenze wird bei Massenproduktion und Verfügbarkeit gezogen. Das was Intel mit den letzten Generationen gemacht hat, ist nur Augenwischerei. Ein oder zwei Modelle können sie aufgrund der D1D Fab sowieso immer abdrücken. Das beeindruckt niemanden. Entscheidend ist, wenn der Markt grossflächig beliefert werden kann. Die Einführung des Penryn ist dir hoffentlich noch im Gedächtnis, wo es selbst Anfang 2008 immer noch arge Lieferprobleme gab.

Vorsicht, nicht in jedem Fall, hier musst du unterscheiden! Für viele Berechungen kann im Voraus bekannt sein, dass sie zu 100% unabhängig sind und hier macht es sehr viel mehr Sinn, diese auch fest in Threads zu unterteilen und das nicht zur Laufzeit entscheiden zu lassen. Und so wirds auch gemacht

Sry, aber ich muss dich nochmal fragen, kannst du lesen? Wir sind immer noch auf µOp Ebene. Es geht um µOp Parallelisierung EINES Code Streams. Multithreading interessiert uns gar nicht.

Eine Definition von SMT oder HT gibt es zur Genüge, die Bedeutung von "reverse" ist auch klar - da braucht man nicht zu diskutieren.

Netter Versuch, nur leider falsch. Es geht ja nicht um den Begriff selbst, sondern um das Konzept. Dieses muss eindeutig definiert sein. Erst dann kannst du einen passenden Begriff wählen. Bisher geisterte das halt alles unter der Bezeichnung Anti-Hyperthreading, Reverse Hyperthreading, Reverse SMT oder was auch immer durchs Netz. Entstanden ist dies wohl aufgrund der Zielsetzung beider Konzepte. Mittels SMT sollen mehrere Threads einen Kern besser ausnutzen, bei Reverse SMT soll wiederum ein Thread mehrere Kerne ausnutzen.

Das ist mir zu allgemein. Schon allein weil parallelisierbar eine weite Formulierung ist, kann ich zweifach, dreifgach, vierfach parallel rechnen?

Das ist für die Diskussion irrelevant. Letztendlich muss die Architektur dafür eine ausreichende Dimensionierung finden. Dass man nicht unendlich Parallelisieren kann, sollte eigentlich klar sein.

Ein gutes Beispiel wäre eine KI-Simulation, hier kannst du maximal so lange parallelisieren bis du auf zwangsläufige Interaktionen stößt, und da ist dann das Ende jeglicher Optimierungen in dieser Beziehung erreicht.

Was immer noch irrelevant ist, ES GEHT UM µOP PARALLELISIERUNG EINES THREADS. Wie oft denn noch? Du denkst zu viel an Multithreading. Das hat mit der Diskussion rund um Reverse SMT nichts zu tun. Das Optimum wäre letztendlich, beides in einer Architektur so zu vereinen, dass immer sämtliche Kapazitäten ausgeschöpft werden können. Und bei Bulldozer scheint dies zumindest in Ansätzen der Fall zu sein.

Siehe Opterons Posting weiter oben, wir reden von einer Umsetzung dieses Patentes:

http://www.patent2pdf.com/pdf/06574725.pdf

Ok, dann solltest du in Zukunft genauer hinschreiben, worauf du dich beziehst. Dann gibt es auch kein Rätselraten.

Ich sprach wie zu lesen von der Aufteilung in Software als Grundstock. Dies jetzt in Hardware zu erweitern ist möglich und kann sinnvoll sein, aber den Softwareweg nicht in sinnvoller Weise vollkommen ersetzen.

Parallelisierung grundsätzlich nicht, das ist richtig. Das hat aber weniger etwas direkt mit Multithreading zu tun, sondern mit Programmlogik und Hardwareanbindung. Multithreading ist letztendlich nur ein Lösungsansatz.

@PitGST
Hast du dich verirrt? Siehe oben. SMT ist hier nicht das Thema.

 

[PitGST]

Für SMT Gespräche--> Der SMT (Simultaneous Multithreading) Laberthread

 

[mr.dude]

Was machst du denn PitGST? Warum verschiebst du sämtliche Beiträge in den anderen Thread? Bei der Diskussion ging es doch überhaupt nicht um SMT.

 

[PitGST]

Was machst du denn PitGST? Warum verschiebst du sämtliche Beiträge in den anderen Thread? Bei der Diskussion ging es doch überhaupt nicht um SMT.

Also wenn ich mit die Beiträge so ansehe wurde über SMT, Parallelisierung und Threads geredet/gequotet.