News Analyse der vermuteten Zen-Architektur
Complicated
Grand Admiral Special
Und inwiefern liest sich das jetzt anders als das was ich schrieb?
Du widersprichst und schreibst das selbe. Ich schrieb auch, dass AMD hier eigene Wege geht und TSX vielleicht überhaupt nicht relevant ist in einem AMD Prozessor, da TSX z.B. bei Unified Memory Access mit HSA überhaupt keinen Sinn macht.
Welche Rolle sollte ASF oder TSX oder Transactional Memory an sich bei HSA Systemen spielen wo jeder heterogene (und ebenso homogene) Prozessor auf gemeinsame oder exklusive Speicherbereiche zugreifen kann mit Hilfe von ZeroCopy und dem HSA-Memory Management?
--- Update ---
Der Link bestätigt Elcaros Aussage. Hast du ihn selbst gelesen?Allerdings würde ich ASF und TSX nicht vergleichen wollen. Die Ausrichtung ist nicht deckungsgleich.
Also sollte die Ausrichtung doch eindeutig die selbe sein.
--- Update ---
Gerade im HSA-Treiber für Linux gefunden:
https://github.com/HSAFoundation/HS...ocumentation/powerpc/transactional_memory.txt
Dieses Feature "atomic meomory access" wird in HSA Hardware auf folgende Weise umgesetzt:
http://www.hsafoundation.com/html/Content/PRM/Topics/06_Memory/atomic_memory.htm
Daher ist es nicht verwunderlich, wenn ASF nicht den Weg in die x86-64 ISA gefunden hat. Und auch nicht verwunderlich, dass Intel genau da TSX benötigt.
Doch warum sollte AMD dieses auch noch unnötigerweise verbauen, wenn eben dieses Feature durch HSA schon bereitgestellt wird (sicherlich ist hier einiges von der Arbeit an ASF eingeflossen) - und das auch noch heterogen.
TSX ist veraltet bevor es überhaupt funktioniert hatte, vor allem in Bezug auf HPC wo es ja einzig eine Rolle spielt. Dort sind GPUs nicht mehr weg zu denken wenn man an die Leistungsspitze will.
gerade bei Wikipedia steht viel Stuß, wenn es um zukünftige Chips geht. Zudem ist dieses "competing" nur eine Formulierung im Fließtext, über die der Schreiber evtl. nicht so gut nachgedacht hat. Als Beleg würde ich das nicht nehmen.
Complicated
Grand Admiral Special
Daher habe ich ja auch die zusätzlichen Quellen aufgeführt.
Der Link zu den HSA Treibern ist sicherlich kein Stuß.
Den meisten ist anscheinend gar nicht klar wofür TSX eigentlich da ist....
Es geht um fine grained "atomic Memory Access" ohne dass der Entwickler den Aufwand betreiben muss beim Memory Management. Das hat absolut gar keinen Nutzen in Desktop Software mit weniger als 16 Threads.
Der Link zu den HSA Treibern ist sicherlich kein Stuß.
Den meisten ist anscheinend gar nicht klar wofür TSX eigentlich da ist....
Es geht um fine grained "atomic Memory Access" ohne dass der Entwickler den Aufwand betreiben muss beim Memory Management. Das hat absolut gar keinen Nutzen in Desktop Software mit weniger als 16 Threads.
Uff. An sich ein netter und informativer Artikel, aber teilweise sträuben sich mir die Nackenhaare. Ich denke, in die wenigen gegebenen Informationen wurde einfach viel zu viel hineininterpretiert.
Latenz der Multiplikationseinheit sind zwei Takte, bei der Additionseinheit drei.
Erwartete Takte pro Iteration ohne Pipeline: 3 Takte * 4 Additionen / 1 Addierer = 12.
Erwartete Takte pro Iteration mit Pipeline: 1 Takt * 4 Additionen / 1 Addierer = 4.
...es sind tatsächlich 4, und Multiplikationseinheit verhält sich genau so. Getestet auf einem Athlon 5350 (Puma == Jaguar).
Dass Zen tatsächlich keine pipelined FPU haben wird, kann ich mir auch nicht recht vorstellen, dann läge die FPU-Gesamtleistung eines hypothetischen Zen-Achtkerners bei den angegebenen Latenzen (die nebenbei ebenfalls sehr hoch, aber zumindest realistisch erscheinen) mal eben unter der eines Phenom II X4. Aber wirklich wissen werden wir es erst zu Release.
Dass Zen die Jaguar-Rechenwerke übernehmen wird, kann ich mir ebenfalls nicht vorstellen - die sind zwar prinzipiell nicht schlecht mit den niedrigen Latenzen, einige Befehle sind aber fürchterlich langsam und hoch takten lassen werden sie sich auch nicht.
Solche Sachen wie Divisionen und genaue Wurzeln werden wahrscheinlich tatsächlich ohne Pipeline ausgeführt, aber das ist eigentlich so üblich - und die werden auch in der Regel sehr selten gebraucht und lassen sich durch schnelleren (pipelined) Code ersetzen, wobei damit auch etwas Genauigkeit aufgegeben wird.
Das wird zwar auch nicht zu 100% stimmen und einige Dinge fehlen darin auch (hauptsächlich speziellere Befehle, aber auch z.B. was mit Speicheroperationen passiert, ob diese FPU-Ressourcen brauchen wie einst bei der FSTORE-Einheit des K10 oder nicht, ...) - aber das sieht für mich relativ ausgeglichen aus. FP3 dürfte die meiste Zeit mit Additionen beschäftigt werden, FP2 mit Shuffle/Permute-Befehlen, FP0 mit Multiplikationen und FP1 mit den bitweisen Operationen, aber bei Bedarf geht auch mal etwas Anderes.
Einen eindeutigen Flaschenhals erkenne ich nicht, für die meisten Befehle existieren wenigstens zwei Pipes.
Die Tabelle auf Seite 3 passt auch nicht. Steamroller und Excavator haben einen Frontend-Durchsatz von 4 Befehlen pro Takt, nicht 2, und die L2-Latenz bei K10 ist AFAIK auch höher (hab aber nichts hier, um das wirklich zu testen).
Wo kommt die Information her? Das stimmt nämlich nicht, was sich mit folgendem Miniprogramm auch wunderbar nachweisen lässt (wenn man nebenher die Performance-Counter der CPU überwacht):Artikel schrieb:
Code:
int main(int argc, char** argv) {
while (1) {
float a = 1.0f;
asm volatile (
"mov rcx, %1;"
"vbroadcastss xmm0, [%0];"
"vxorps xmm1, xmm1, xmm1;"
"vmovaps xmm2, xmm1;"
"vmovaps xmm3, xmm1;"
"vmovaps xmm4, xmm1;"
".align 32; 1:"
"vaddps xmm1, xmm1, xmm0;"
"vaddps xmm2, xmm2, xmm0;"
"vaddps xmm3, xmm3, xmm0;"
"vaddps xmm4, xmm4, xmm0;"
"inc rcx;"
"jnz 1b;"
:
: "m" (a), "i" (1000000)
: "rcx", "xmm0", "xmm1", "xmm2", "xmm3", "xmm4"
);
}
return 0;
}Latenz der Multiplikationseinheit sind zwei Takte, bei der Additionseinheit drei.
Erwartete Takte pro Iteration ohne Pipeline: 3 Takte * 4 Additionen / 1 Addierer = 12.
Erwartete Takte pro Iteration mit Pipeline: 1 Takt * 4 Additionen / 1 Addierer = 4.
...es sind tatsächlich 4, und Multiplikationseinheit verhält sich genau so. Getestet auf einem Athlon 5350 (Puma == Jaguar).
Dass Zen tatsächlich keine pipelined FPU haben wird, kann ich mir auch nicht recht vorstellen, dann läge die FPU-Gesamtleistung eines hypothetischen Zen-Achtkerners bei den angegebenen Latenzen (die nebenbei ebenfalls sehr hoch, aber zumindest realistisch erscheinen) mal eben unter der eines Phenom II X4. Aber wirklich wissen werden wir es erst zu Release.
Dass Zen die Jaguar-Rechenwerke übernehmen wird, kann ich mir ebenfalls nicht vorstellen - die sind zwar prinzipiell nicht schlecht mit den niedrigen Latenzen, einige Befehle sind aber fürchterlich langsam und hoch takten lassen werden sie sich auch nicht.
Solche Sachen wie Divisionen und genaue Wurzeln werden wahrscheinlich tatsächlich ohne Pipeline ausgeführt, aber das ist eigentlich so üblich - und die werden auch in der Regel sehr selten gebraucht und lassen sich durch schnelleren (pipelined) Code ersetzen, wobei damit auch etwas Genauigkeit aufgegeben wird.
AVX hat keine logarithmischen Operationen (und SSE schon gar nicht). "log" steht wohl eher für die bitweisen AND(N)/OR/XOR-Operationen.Artikel schrieb:
Klingt irreführend, Doubles sind im normalen Sprachgebrauch eigentlich 64 Bit-Floating Point-Zahlen. Gemeint sind wohl eher "DirectPath Double"-Befehle, um es mal mit AMDs Vokabular zu sagen, also Befehle, die zwei µOps erzeugen.Artikel schrieb:
Wobei man sich das mal anschauen müsste, wenn man die ganzen redundanten Einträge entfernt und sich anschaut, welche Befehlsarten denn damit verbunden sind. Hier mal ein Versuch:Artikel schrieb:
Code:
FP 0 FP 1 FP 2 FP 3
# Float
vfmadd (1/2) vfmadd (1/2) vfmadd (2/2?) vfmadd (2/2)
vmul vmul vadd/vsub vadd/vsub
vcmp vcmp (?) vcvt
vand/vxor/vor vand/vxor/vor
vcomi vcomi vdiv
vblend (?) vblend (?) vround (?)
vmin/vmax (?) vmin/vmax (?)
vrcp/vrsqrt (?) vrcp/vrsqrt (?)
vshuf/vperm vshuf/vperm
# Integer
vpadd/vpsub vpadd/vpsub vpsl/vpsr vpadd/vpsub
vpcmp vpand/vpxor/vpor vpand/vpxor/vpor vpcmp
vpmul vptest vpmul
vpshuf vpshufDas wird zwar auch nicht zu 100% stimmen und einige Dinge fehlen darin auch (hauptsächlich speziellere Befehle, aber auch z.B. was mit Speicheroperationen passiert, ob diese FPU-Ressourcen brauchen wie einst bei der FSTORE-Einheit des K10 oder nicht, ...) - aber das sieht für mich relativ ausgeglichen aus. FP3 dürfte die meiste Zeit mit Additionen beschäftigt werden, FP2 mit Shuffle/Permute-Befehlen, FP0 mit Multiplikationen und FP1 mit den bitweisen Operationen, aber bei Bedarf geht auch mal etwas Anderes.
Einen eindeutigen Flaschenhals erkenne ich nicht, für die meisten Befehle existieren wenigstens zwei Pipes.
L1 ja, L2 nein. Der L2 ist bei den Katzen ein 2 MB großer und relativ langsamer Shared LLC, bei Zen wird er höchstwahrscheinlich ein lokaler Cache sein, vor dem dann noch ein L3 sitzt, über den man sich aber leider generell viel zu wenig unterhält. Und zwar allein schon, weil sich die Weisheit von Anandtech aus deren Phenom II-Test (den ich aus irgendwelchen Gründen nicht verlinken darf), "L2: It’s the New L1", bewahrheitet hat und sicherlich auch einer der Gründe ist, warum Bulldozer so gescheitert ist.Artikel schrieb:
Die Tabelle auf Seite 3 passt auch nicht. Steamroller und Excavator haben einen Frontend-Durchsatz von 4 Befehlen pro Takt, nicht 2, und die L2-Latenz bei K10 ist AFAIK auch höher (hab aber nichts hier, um das wirklich zu testen).
Zuletzt bearbeitet:
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Neulinge dürfen erst mal nichts verlinken
was allerdings in deinem Falle wirklich bedauerlich ist
@ VikingGe Ach ja, erst mal Danke und herzlich willkommen auf P3D!
MFG Bobo(2015)
Das "nicht pipelined" betrifft eigentlich vorwiegend die Multiplikation. In dem Compiler Update steht nämlich:
+(define_insn_reservation "znver1_ssemul_avx256_ps" 3
+ (and (eq_attr "cpu" "znver1")
+ (and (eq_attr "mode" "V8SF")
+ (and (eq_attr "type" "ssemul")
+ (eq_attr "memory" "none"))))
+ "znver1-double,(znver1-fp0|znver1-fp1)*3")
Das *3 sollte hier bedeuten, dass der Befehl nur alle 3 Takte möglich ist. Vielleicht ist das aber auch noch ein fehlerhafter Eintrag. Fast alle anderen FP Befehle haben hier keine Einschränkung, sind also voll pipelined. FPVDIV z.b. ist mit *12 gekennzeichnet, das normale FMUL (x87?) sogar mit *5 und ist auch auf Port0 beschränkt.
Wobei nicht pipelind auch nicht ganz stimmt, denn die Latenz liegt bei 6 Takte (FADD, FMUL) bzw. 42 Takte (FDIV), also eben eher nicht voll pipelined.
AVX_MOV_LOD/STORE werden einem beliebign AGU Port und einem beliebigen FP Port zugewiesen. Andere kombinierte AVX/LD/ST Befehle gehen auch alle auf die AGU. Einen reinen Store/Load hab ich grad auf die schnelle nicht gefunden, der sollte dann aber auch nur die AGU betreffen.
Die L2 Latenz bei K10 hab ich auch höher in Erinnerung. Der L2 bei Zen ist aber auf alle Fälle lokal für einen Kern und einen shared L3 soll es für die Zen CPUs dann auch geben.
Und auch von mir ein Willkommen.
+(define_insn_reservation "znver1_ssemul_avx256_ps" 3
+ (and (eq_attr "cpu" "znver1")
+ (and (eq_attr "mode" "V8SF")
+ (and (eq_attr "type" "ssemul")
+ (eq_attr "memory" "none"))))
+ "znver1-double,(znver1-fp0|znver1-fp1)*3")
Das *3 sollte hier bedeuten, dass der Befehl nur alle 3 Takte möglich ist. Vielleicht ist das aber auch noch ein fehlerhafter Eintrag. Fast alle anderen FP Befehle haben hier keine Einschränkung, sind also voll pipelined. FPVDIV z.b. ist mit *12 gekennzeichnet, das normale FMUL (x87?) sogar mit *5 und ist auch auf Port0 beschränkt.
Wobei nicht pipelind auch nicht ganz stimmt, denn die Latenz liegt bei 6 Takte (FADD, FMUL) bzw. 42 Takte (FDIV), also eben eher nicht voll pipelined.
AVX_MOV_LOD/STORE werden einem beliebign AGU Port und einem beliebigen FP Port zugewiesen. Andere kombinierte AVX/LD/ST Befehle gehen auch alle auf die AGU. Einen reinen Store/Load hab ich grad auf die schnelle nicht gefunden, der sollte dann aber auch nur die AGU betreffen.
Die L2 Latenz bei K10 hab ich auch höher in Erinnerung. Der L2 bei Zen ist aber auf alle Fälle lokal für einen Kern und einen shared L3 soll es für die Zen CPUs dann auch geben.
Und auch von mir ein Willkommen.
Ich hoffe es. Blöderweise passt das aber tatsächlich dazu, dass nur eine Pipe FMA können soll.
Aber falls das doch stimmt, braucht man Zen eigentlich gar nicht zu veröffentlichen. Die Multiplikation ist die wichtigste FP-Operation überhaupt, und wenn der Multiplikations- und FMA-Durchsatz gegenüber Bulldozer mal eben gedrittelt (bzw. bei Double Precision sogar geviertelt und damit auf K8-Niveau reduziert) wird, wird man bei FPU-lastigen Anwendungen, die nicht gerade im Speicherbandbreitenlimit hängen, nicht ansatzweise eine Chance haben. Möglicherweise nicht einmal gegen die Vorgänger, die entweder an unausgewogenem Pipeline-Layout (Bulldozer, Piledriver) oder extrem schlechtem Scheduling (K10) kranken.
Ich meine, die Multiplikation ist mit Abstand die wichtigste FP-Operation, auf jede Addition kommt in der Regel mehr als eine Multiplikation. Da braucht es Durchsatz, Durchsatz, Durchsatz...
Zuletzt bearbeitet:
Bereits Bulldozer fand ich bei der FPU Performance gegenüber K10 richtig schwach ausgelegt, es zählt nur das was hinten rauskommt!
AMD muss sowohl bei IPC als auch bei FPU Performance kräftig nach oben schießen, 50% mehr IPC & 50% mehr FPU Performance als Bulldozer.
AMD muss sowohl bei IPC als auch bei FPU Performance kräftig nach oben schießen, 50% mehr IPC & 50% mehr FPU Performance als Bulldozer.
Complicated
Grand Admiral Special
50% mehr IPC...warum? Es sind ein Plus von 40% angekündigt von AMD bei der IPC (gegenüber Excavator, was sogar über 50% mehr IPC zu Bulldozer bedeutet). Daran müssen sie sich messen lassen.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Danke und auch von mir ein herzlich Willkommen im Forum
Oho, Assemblercode ... wow nicht schlecht
Danke für den Code. Allerdings hats tex_ ja schon gesagt .. der Textabschnitt bezog sich nur auf die Multiplilatoreinheiten, steht auch im Text, dachte das wär damit eindeutig:
Der Kontext ging dann aber zugegeben etwas verloren, weil ich mich nach dem Schreiben noch entschied das FP-Bildchen einzufügen, ich änder mal einfach das FPU in "Multiplikatoreinheiten", dann ists in jedem Fall klar, insbesondere auch für Leute die nur abschnittsweise lesen
Tja .. aber das Codefragment weisst halt darauf hin, denn die gleichen Wartezyklen gibts bei Puma auch .. wobei festzustellen ist, dass Zens Mul-Einheit mehr Takte braucht. Das ist <leider> stimmig ... wenn man das Zen-Design ggü. den Cats höher takten will, aber die Schaltkreise beibehält.
Ahh sorry ... stimmt, das verwechsle ich immer gerne ... log steht ja auch für "LOGische" Operationen ... willkommen im Abkürzungsjungle
Na Du hast es doch verstanden
Außerdem sollte man wissen was gemeint ist. Erstens hab ich den Begriff vorher eingeführt:
Zweitens weiss ich in dem von Dir zitierten Abschnitt explizit mit "wie die bereits erwähnten 256-Bit-Befehle" darauf hin. Von daher sollte ein Leser des Gesamttextes keine Probleme haben.
Jo kann man machen - NOCH mehr Zeit wollte ich aber nicht mehr investieren, möglicherweise sind die Einträge ja noch fehlerhaft.
Die wichtigstens Funktionen sind ADD und MUL, die sind gut verteilt, MUL auf FP0/1, ADD auf FP2/3.
Soweit so gut ... ist halt jetzt die Frage, wieviel "Unterports" es noch gibt, bzw. welche Rechenwerke noch am gleichen Port hängen. FP3 hat da mMn nach mehr, DIV, IMUL,CVT und die FMA-Weiterleitung.
In Deiner Auflistung hast Du ziemlich viel bei FP2, aber mehr als Shuffle und die Logikoperatoren ist das nicht. Normalerweise nehmen solche Sachen wenig Die-Fläche weg, das ist einfach zu haben. Aber vielleicht hat da AMD auch mehr Transistoren investiert ... das kommt dann ganz auf die Implementierung an. Aber mehr will ich wie besagt nicht analysieren, am Ende ist alles für die Katz'.
Du denkst zu simpel
Größe ist doch nicht alles, die Implementierung machts ... und das ist bei den Katzen so gelöst, dass jeder Kern seinen eigenen 512kB-Teil im gemeinsam benutzten Cache hat. Da laufen pro Kern 512bit-Leitungen hin, will man auf die anderen Segmente zugreifen dauert es extra. So ein Design also in vier eigene 512kB L1-Caches aufzudröseln ist kein großes Problem. Genauer wollte ich das nicht aufführen, aus dem bereits genannten Grund, vielleicht stimmts am Ende nicht.Ja der relativ langsame L2 wird seinen Teil am Fiakso gehabt haben. Sieht man schön auch am Excavator-Design ... doppelt soviel L1 (2x32 statt 2x16), halb soviel L2 (1MB weniger(!)) -> Mehr IPC.
Aus Die-Flächensicht ein Witz .. auch wenn man den L1 zweimal pro Cluster braucht. Vermutlich standen einem komplexeren L1-Design (die Assoziativität nahm ja auch zu) die alten Taktziele im Wege ... mit Excavator kann man sagen, dass das an der falschen Stelle gespart war.
Ja bei 2 Threads .. aber nicht für einen Thread, ab Steamroller gabs doch getrennte Decoder für beide INT-Cluster. Bei Bulldozer_v1 hätte da 4 stehen können, wobei es dort aber auf 4 Instruktionen pro 2 Takte für je einen Cluster begrenzt war .. also im Schnitt ebenfalls nur 2. CMT ist halt immer etwas schwierig in ner Tabelle darzustellen.
Ja, aber die 10 stehen im AMD-PDF als best-case. Nachdem ich die Intel-Zahlen auch aus dem Intel-PDF nahm und die ebenfalls best case sind, nahm ich auch die 10 für AMD.
Wenn man nur ne CPU hat - ja. Aber es ist ja eine High-End-APU/Opteron angedacht. Dort gibts dann Durchsatz zum abwinken. Eine CPU-FPU sollte v.a. eine gute Latenz haben, Durchsatz ist im Zeitalter von GPGPU nicht mehr alles, Arbeitsteilung ist angesagt.
Als Ausgleich / Zugeständnis zum schlechten Durchsatz der Cat-Familie gibts halt dafür gleich 2 der "schlechten" MUL-Einheiten, das könnte ein ganz guter Kompromiss sein, wenn man SMT abschaltet.
Man darf nicht vergessen, das Hauptdesignziel ist "Perf/Watt" und nicht "Leistung koste es was es wolle". Das waren eher die 220W - Bulldozer. Das würde auch passend zum Codenamen "Zen" sein. Alles etwas geruhsamer angehen ... denn die Brechstange Bulldozer mit 5 GHz war ein Flop.
@tex_: Danke für den Tipp mit den "Fully pipelined" ergänz ich mal auch noch.<leider></leider></leider>
Wobei Bulldozers FPU an sich schon besser ist als die von K10. Scheduling läuft besser (K10 schaufelt gerne alles in die ohnehin meist überforderte FMUL-Pipe, BD verteilt das deutlich sinnvoller), beide FMA-Pipes können sowohl addieren als auch multiplizieren und mit FMA ist die theoretische Rohleistung auch noch deutlich höher.Duplex schrieb:
Problem 1: Die Latenzen sind extrem hoch.
Problem 2: Man hat nur 4 Stück davon statt - wie zuvor - 6.
Problem 3: Es gibt zu viele Nebenbefehle, die in nur einer der beiden FMA-Einheiten ablaufen und diese damit blockieren.
Wie gesagt, die Multiplikationseinheiten verhalten sich bei dem Athlon mit Jaguar-Kernen absolut identisch und sind damit fully pipelined. Das sagt übrigens auch AMD selbst im Fam16h Software Optimization Guide.Opteron schrieb:
Das kann gerne mal jemand mit einem Beema/Carrizo-L gegentesten, aber die Architektur ist meines Wissens nach exakt dieselbe.
Edit: Das ganze gilt für 128 Bit-Multiplikationen. 256 Bit-Operationen erzeugen 2 µOps für dieselbe Pipeline, da geht dann wirklich nur ein Befehl alle zwei Takte. Aber das betrifft Additionen in dem Fall genau so.
Edit 2: Okay, auch das stimmt nur so halb. Für Double Precision ist die Multiplikationseinheit wohl wirklich nicht pipelined (8 Takte, wenn man im Beispielcode das vaddps durch vmulpd ersetzt), für Single Precision aber sehr wohl. Bei Zen sind allerdings bisher beide Fälle ohne Pipeline angegeben.
Siehe oben.Opteron schrieb:
Ja, etwas suboptimal finde ich die Wortwahl trotzdemOpteron schrieb:
Mag ja sein, dass die Latenzen für die anderen Bereiche etwas höher sind, vergleichbar mit einem lokalen Cache ist es dadurch aber nicht. Einmal hat ein einzelner Kern Zugriff auf die gesamten 2 MB, andererseits leidet unter dem Shared-Aspekt die parallele Schreibleistung ganz massiv. Die liegt bei Multithreaded-Zugriff gerade mal bei ~40% der Leseleistung, bei Single Thread-Zugriff sind es noch ~85%. Und das selbstverständlich bei unterschiedlichen Speicherbereichen.Opteron schrieb:Du denkst zu simpel
Code:
$ ./bandwidth --threads 1
CPU vendor: AuthenticAMD
CPU model: AMD Athlon(tm) 5350 APU with Radeon(tm) R3
Supports PREFETCHW: Yes
read read [t0] read [nta]
1 kB: 33.56 GB/s 26.83 GB/s 26.85 GB/s
2 kB: 30.50 GB/s 24.91 GB/s 24.91 GB/s
3 kB: 31.45 GB/s 25.53 GB/s 25.55 GB/s
4 kB: 32.01 GB/s 25.84 GB/s 25.86 GB/s
6 kB: 32.49 GB/s 26.17 GB/s 26.19 GB/s
8 kB: 32.79 GB/s 26.34 GB/s 26.35 GB/s
12 kB: 33.05 GB/s 26.51 GB/s 26.52 GB/s
16 kB: 33.17 GB/s 26.59 GB/s 26.60 GB/s
24 kB: 33.30 GB/s 26.68 GB/s 26.68 GB/s
32 kB: 31.86 GB/s 25.62 GB/s 25.25 GB/s
48 kB: 15.71 GB/s 16.67 GB/s 16.65 GB/s
64 kB: 15.73 GB/s 16.70 GB/s 16.68 GB/s
96 kB: 15.75 GB/s 16.73 GB/s 16.72 GB/s
128 kB: 15.76 GB/s 16.74 GB/s 16.73 GB/s
192 kB: 15.77 GB/s 16.76 GB/s 16.75 GB/s
256 kB: 15.78 GB/s 16.76 GB/s 16.75 GB/s
384 kB: 15.78 GB/s 16.77 GB/s 16.77 GB/s
512 kB: 15.78 GB/s 16.77 GB/s 16.77 GB/s
768 kB: 15.79 GB/s 16.79 GB/s 16.79 GB/s
1024 kB: 15.75 GB/s 16.77 GB/s 16.66 GB/s
1536 kB: 15.77 GB/s 16.79 GB/s 13.42 GB/s
2 MB: 12.89 GB/s 15.07 GB/s 10.51 GB/s
3 MB: 5.96 GB/s 6.19 GB/s 8.34 GB/s
4 MB: 5.94 GB/s 6.16 GB/s 7.71 GB/s
6 MB: 5.96 GB/s 6.19 GB/s 7.12 GB/s
8 MB: 5.95 GB/s 6.16 GB/s 6.90 GB/s
12 MB: 6.03 GB/s 6.26 GB/s 6.76 GB/s
16 MB: 5.93 GB/s 6.15 GB/s 6.55 GB/s
24 MB: 6.03 GB/s 6.26 GB/s 6.53 GB/s
32 MB: 5.93 GB/s 6.16 GB/s 6.39 GB/s
48 MB: 6.33 GB/s 6.57 GB/s 6.76 GB/s
64 MB: 5.93 GB/s 6.16 GB/s 6.31 GB/s
write write [w] write [nt] write [stosq] write [memset]
1 kB: 33.31 GB/s 26.85 GB/s 3.79 GB/s 13.18 GB/s 26.20 GB/s
2 kB: 29.85 GB/s 24.47 GB/s 4.07 GB/s 18.85 GB/s 24.84 GB/s
3 kB: 30.99 GB/s 25.22 GB/s 4.21 GB/s 22.07 GB/s 27.19 GB/s
4 kB: 31.61 GB/s 25.61 GB/s 4.29 GB/s 23.35 GB/s 28.55 GB/s
6 kB: 32.23 GB/s 26.02 GB/s 4.41 GB/s 25.99 GB/s 30.05 GB/s
8 kB: 32.55 GB/s 26.22 GB/s 4.41 GB/s 27.02 GB/s 30.86 GB/s
12 kB: 32.88 GB/s 26.43 GB/s 4.53 GB/s 28.52 GB/s 31.70 GB/s
16 kB: 33.05 GB/s 26.52 GB/s 4.53 GB/s 29.31 GB/s 32.14 GB/s
24 kB: 33.22 GB/s 26.63 GB/s 4.59 GB/s 30.18 GB/s 32.61 GB/s
32 kB: 30.58 GB/s 22.09 GB/s 4.61 GB/s 30.62 GB/s 27.54 GB/s
48 kB: 14.21 GB/s 13.09 GB/s 4.65 GB/s 14.31 GB/s 14.18 GB/s
64 kB: 14.36 GB/s 13.17 GB/s 4.65 GB/s 14.38 GB/s 14.31 GB/s
96 kB: 14.42 GB/s 13.22 GB/s 4.65 GB/s 14.44 GB/s 14.32 GB/s
128 kB: 14.30 GB/s 13.21 GB/s 4.66 GB/s 14.49 GB/s 14.43 GB/s
192 kB: 14.37 GB/s 13.27 GB/s 4.69 GB/s 14.58 GB/s 14.31 GB/s
256 kB: 14.29 GB/s 13.29 GB/s 4.67 GB/s 14.59 GB/s 14.26 GB/s
384 kB: 14.27 GB/s 13.29 GB/s 4.70 GB/s 14.60 GB/s 14.24 GB/s
512 kB: 14.39 GB/s 13.30 GB/s 4.68 GB/s 14.54 GB/s 14.34 GB/s
768 kB: 14.39 GB/s 13.32 GB/s 4.68 GB/s 14.48 GB/s 14.37 GB/s
1024 kB: 14.34 GB/s 13.32 GB/s 4.67 GB/s 14.62 GB/s 14.50 GB/s
1536 kB: 14.33 GB/s 13.34 GB/s 4.67 GB/s 14.30 GB/s 14.31 GB/s
2 MB: 10.19 GB/s 9.77 GB/s 4.69 GB/s 10.17 GB/s 9.91 GB/s
3 MB: 3.62 GB/s 3.64 GB/s 4.69 GB/s 3.63 GB/s 3.62 GB/s
4 MB: 3.62 GB/s 3.63 GB/s 4.68 GB/s 3.60 GB/s 3.62 GB/s
6 MB: 3.61 GB/s 3.60 GB/s 4.70 GB/s 3.61 GB/s 3.61 GB/s
8 MB: 3.60 GB/s 3.60 GB/s 4.68 GB/s 3.60 GB/s 3.60 GB/s
12 MB: 3.67 GB/s 3.66 GB/s 4.75 GB/s 3.67 GB/s 3.67 GB/s
16 MB: 3.60 GB/s 3.59 GB/s 4.68 GB/s 3.60 GB/s 3.59 GB/s
24 MB: 3.66 GB/s 3.65 GB/s 4.74 GB/s 3.66 GB/s 3.66 GB/s
32 MB: 3.60 GB/s 3.60 GB/s 4.67 GB/s 3.60 GB/s 3.60 GB/s
48 MB: 3.84 GB/s 3.83 GB/s 4.98 GB/s 3.84 GB/s 3.84 GB/s
64 MB: 3.60 GB/s 3.59 GB/s 4.67 GB/s 3.59 GB/s 3.60 GB/s
$ ./bandwidth --threads 4
CPU vendor: AuthenticAMD
CPU model: AMD Athlon(tm) 5350 APU with Radeon(tm) R3
Supports PREFETCHW: Yes
read read [t0] read [nta]
1 kB: 134.27 GB/s 107.43 GB/s 107.43 GB/s
2 kB: 122.23 GB/s 99.63 GB/s 99.64 GB/s
3 kB: 125.94 GB/s 102.11 GB/s 102.21 GB/s
4 kB: 127.87 GB/s 103.32 GB/s 103.41 GB/s
6 kB: 130.08 GB/s 104.56 GB/s 104.75 GB/s
8 kB: 131.16 GB/s 105.37 GB/s 105.41 GB/s
12 kB: 132.21 GB/s 105.86 GB/s 106.02 GB/s
16 kB: 132.72 GB/s 106.38 GB/s 106.40 GB/s
24 kB: 133.21 GB/s 106.72 GB/s 106.72 GB/s
32 kB: 127.30 GB/s 102.38 GB/s 100.98 GB/s
48 kB: 62.61 GB/s 66.38 GB/s 66.20 GB/s
64 kB: 62.83 GB/s 66.55 GB/s 66.43 GB/s
96 kB: 62.93 GB/s 66.75 GB/s 66.65 GB/s
128 kB: 62.96 GB/s 66.83 GB/s 66.76 GB/s
192 kB: 63.03 GB/s 66.95 GB/s 64.08 GB/s
256 kB: 62.93 GB/s 66.94 GB/s 63.67 GB/s
384 kB: 62.95 GB/s 66.94 GB/s 59.10 GB/s
512 kB: 49.39 GB/s 56.54 GB/s 33.94 GB/s
768 kB: 8.89 GB/s 8.89 GB/s 19.72 GB/s
1024 kB: 8.76 GB/s 8.80 GB/s 14.30 GB/s
1536 kB: 8.77 GB/s 8.81 GB/s 11.90 GB/s
2 MB: 8.77 GB/s 8.80 GB/s 12.73 GB/s
3 MB: 8.81 GB/s 8.83 GB/s 10.11 GB/s
4 MB: 8.78 GB/s 8.80 GB/s 9.73 GB/s
6 MB: 8.82 GB/s 8.83 GB/s 9.44 GB/s
8 MB: 8.79 GB/s 8.80 GB/s 9.05 GB/s
12 MB: 8.93 GB/s 8.94 GB/s 9.19 GB/s
16 MB: 8.79 GB/s 8.80 GB/s 8.96 GB/s
24 MB: 8.93 GB/s 8.94 GB/s 9.07 GB/s
32 MB: 8.79 GB/s 8.79 GB/s 8.78 GB/s
48 MB: 9.36 GB/s 9.38 GB/s 9.40 GB/s
64 MB: 8.79 GB/s 8.80 GB/s 8.74 GB/s
write write [w] write [nt] write [stosq] write [memset]
1 kB: 133.24 GB/s 107.43 GB/s 4.66 GB/s 52.73 GB/s 102.37 GB/s
2 kB: 119.41 GB/s 97.94 GB/s 4.68 GB/s 75.39 GB/s 99.35 GB/s
3 kB: 123.97 GB/s 100.91 GB/s 4.71 GB/s 88.29 GB/s 108.62 GB/s
4 kB: 126.34 GB/s 102.46 GB/s 4.70 GB/s 93.41 GB/s 115.07 GB/s
6 kB: 128.91 GB/s 104.07 GB/s 4.69 GB/s 103.96 GB/s 120.20 GB/s
8 kB: 130.21 GB/s 104.89 GB/s 4.69 GB/s 108.09 GB/s 123.51 GB/s
12 kB: 131.54 GB/s 105.72 GB/s 4.69 GB/s 114.07 GB/s 126.92 GB/s
16 kB: 132.07 GB/s 106.08 GB/s 4.70 GB/s 117.20 GB/s 128.75 GB/s
24 kB: 132.84 GB/s 106.39 GB/s 4.68 GB/s 120.73 GB/s 130.42 GB/s
32 kB: 124.98 GB/s 88.29 GB/s 4.68 GB/s 122.42 GB/s 105.97 GB/s
48 kB: 27.46 GB/s 26.23 GB/s 4.68 GB/s 27.51 GB/s 27.37 GB/s
64 kB: 27.45 GB/s 26.27 GB/s 4.68 GB/s 27.50 GB/s 27.39 GB/s
96 kB: 27.47 GB/s 26.31 GB/s 4.67 GB/s 27.51 GB/s 27.43 GB/s
128 kB: 27.48 GB/s 26.32 GB/s 4.67 GB/s 27.51 GB/s 27.45 GB/s
192 kB: 27.50 GB/s 26.35 GB/s 4.68 GB/s 27.51 GB/s 27.48 GB/s
256 kB: 27.50 GB/s 26.35 GB/s 4.68 GB/s 27.51 GB/s 27.48 GB/s
384 kB: 27.43 GB/s 26.32 GB/s 4.68 GB/s 27.47 GB/s 27.45 GB/s
512 kB: 24.55 GB/s 24.04 GB/s 4.68 GB/s 24.68 GB/s 24.72 GB/s
768 kB: 3.39 GB/s 3.35 GB/s 4.68 GB/s 3.40 GB/s 3.37 GB/s
1024 kB: 3.29 GB/s 3.27 GB/s 4.68 GB/s 3.28 GB/s 3.29 GB/s
1536 kB: 3.33 GB/s 3.30 GB/s 4.68 GB/s 3.32 GB/s 3.33 GB/s
2 MB: 3.33 GB/s 3.29 GB/s 4.68 GB/s 3.31 GB/s 3.31 GB/s
3 MB: 3.34 GB/s 3.32 GB/s 4.69 GB/s 3.34 GB/s 3.34 GB/s
4 MB: 3.33 GB/s 3.31 GB/s 4.68 GB/s 3.32 GB/s 3.33 GB/s
6 MB: 3.35 GB/s 3.32 GB/s 4.69 GB/s 3.34 GB/s 3.34 GB/s
8 MB: 3.33 GB/s 3.30 GB/s 4.68 GB/s 3.33 GB/s 3.33 GB/s
12 MB: 3.39 GB/s 3.36 GB/s 4.75 GB/s 3.39 GB/s 3.38 GB/s
16 MB: 3.34 GB/s 3.31 GB/s 4.68 GB/s 3.34 GB/s 3.33 GB/s
24 MB: 3.38 GB/s 3.36 GB/s 4.75 GB/s 3.39 GB/s 3.38 GB/s
32 MB: 3.33 GB/s 3.31 GB/s 4.68 GB/s 3.34 GB/s 3.33 GB/s
48 MB: 3.56 GB/s 3.53 GB/s 4.99 GB/s 3.55 GB/s 3.56 GB/s
64 MB: 3.38 GB/s 3.31 GB/s 4.68 GB/s 3.33 GB/s 3.33 GB/sAb davon - 512kB L2-Cache gab es schon bei K8 und K10, das ist jetzt nichts, wo ich unbedingt auf die Katzen schließen würde.
Doch, gerade für einen Thread. Die Anzahl der Decoder-Einheiten wurde bei Steamroller verdoppelt, IPC-Raten weit jenseits der 2 lassen sich bei entsprechendem Code auch beobachten.Opteron schrieb:
Deswegen sollte sowas auch so häufig wie möglich verbaut werden. Laut Compiler-Patch können die Logikoperationen übrigens auf allen vier FP-Pipes ausgeführt werden, da fehlt entweder ein Eintrag im Schaubild oder ich habe ihn einfach übersehen.Opteron schrieb:
Zuletzt bearbeitet:
WindHund
Grand Admiral Special
Pb 1: liegt am Hardware nahen Intel Compiler
Pb 2: Wie 4 gegen 6? das sind 4x256Bit vs. 6x128Bit ?
Pb 3: Es gibt zu viele Einschränkungen Seitens der Compiler Flags, wer sie kennt wird glücklich.
Ähnliche Themen
