App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
News Analyse der vermuteten Zen-Architektur
Complicated
Grand Admiral Special
- Mitglied seit
- 08.10.2010
- Beiträge
- 4.949
- Renomée
- 441
- Mein Laptop
- Lenovo T15, Lenovo S540
- Prozessor
- AMD Ryzen 7 3700X
- Mainboard
- MSI X570-A PRO
- Kühlung
- Scythe Kama Angle - passiv
- Speicher
- 32 GB (4x 8 GB) G.Skill TridentZ Neo DDR4-3600 CL16-19-19-39
- Grafikprozessor
- Sapphire Radeon RX 5700 Pulse 8GB PCIe 4.0
- Display
- 27", Lenovo, 2560x1440
- SSD
- 1 TB Gigabyte AORUS M.2 PCIe 4.0 x4 NVMe 1.3
- HDD
- 2 TB WD Caviar Green EADS, NAS QNAP
- Optisches Laufwerk
- Samsung SH-223L
- Gehäuse
- Lian Li PC-B25BF
- Netzteil
- Corsair RM550X ATX Modular (80+Gold) 550 Watt
- Betriebssystem
- Win 10 Pro.
Und inwiefern liest sich das jetzt anders als das was ich schrieb?Du stellst dich heute aber an. Ich wollte nur mit einem sprachlichen Missverständnis aufräumen:
Elcaros hat nicht mehr und nicht weniger gesagt, dass ASF zwar spezifiziert ist, aber noch in der Praxis angelangt ist.
Ander als TSX, welches in Haswell, Broadwell und Skylake (teils experimentell) bereits implementiert wurde.
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?Advanced Synchronization Facility (ASF) is a proposed extension to the x86-64 instruction set architecture that adds hardware transactional memory support. It was introduced by AMD; the latest specification was dated March 2009.[SUP][1][/SUP] As of October 2013, it was still in the proposal stage.[SUP][2][/SUP] No released microprocessors implement the extension.
--- 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.Transactional Synchronization Extensions, Intel's competing technology first implemented in the Haswell-based microprocessors.
--- 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:Hardware Transactional Memory is supported on POWER8 processors, and is a feature that enables a different form of atomic memory access.
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.
OBrian
Moderation MBDB, ,
- Mitglied seit
- 16.10.2000
- Beiträge
- 17.033
- Renomée
- 267
- Standort
- NRW
- Prozessor
- Phenom II X4 940 BE, C2-Stepping (undervolted)
- Mainboard
- Gigabyte GA-MA69G-S3H (BIOS F7)
- Kühlung
- Noctua NH-U12F
- Speicher
- 4 GB DDR2-800 ADATA/OCZ
- Grafikprozessor
- Radeon HD 5850
- Display
- NEC MultiSync 24WMGX³
- SSD
- Samsung 840 Evo 256 GB
- HDD
- WD Caviar Green 2 TB (WD20EARX)
- Optisches Laufwerk
- Samsung SH-S183L
- Soundkarte
- Creative X-Fi EM mit YouP-PAX-Treibern, Headset: Sennheiser PC350
- Gehäuse
- Coolermaster Stacker, 120mm-Lüfter ersetzt durch Scythe S-Flex, zusätzliche Staubfilter
- Netzteil
- BeQuiet 500W PCGH-Edition
- Betriebssystem
- Windows 7 x64
- Webbrowser
- Firefox
- Verschiedenes
- Tastatur: Zowie Celeritas Caseking-Mod (weiße Tasten)
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.Also sollte die Ausrichtung doch eindeutig die selbe sein.
Complicated
Grand Admiral Special
- Mitglied seit
- 08.10.2010
- Beiträge
- 4.949
- Renomée
- 441
- Mein Laptop
- Lenovo T15, Lenovo S540
- Prozessor
- AMD Ryzen 7 3700X
- Mainboard
- MSI X570-A PRO
- Kühlung
- Scythe Kama Angle - passiv
- Speicher
- 32 GB (4x 8 GB) G.Skill TridentZ Neo DDR4-3600 CL16-19-19-39
- Grafikprozessor
- Sapphire Radeon RX 5700 Pulse 8GB PCIe 4.0
- Display
- 27", Lenovo, 2560x1440
- SSD
- 1 TB Gigabyte AORUS M.2 PCIe 4.0 x4 NVMe 1.3
- HDD
- 2 TB WD Caviar Green EADS, NAS QNAP
- Optisches Laufwerk
- Samsung SH-223L
- Gehäuse
- Lian Li PC-B25BF
- Netzteil
- Corsair RM550X ATX Modular (80+Gold) 550 Watt
- Betriebssystem
- Win 10 Pro.
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:Seit dem K7 waren AMDs FPUs immer „pipelined”, d.h. sie konnten die Befehle wie am Fließband abarbeiten, mitunter also jeden Takt Befehle entgegennehmen. Nur die kleine FPU der Puma-Kerne war nicht pipelined.
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:FP1 und FP2 sind die Kandidaten für logarithmische Berechnungen mit AVX.
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:Zwar gibt es auch eine FMA-Fähigkeit, allerdings diese wird - wie die bereits erwähnten 256-Bit-Befehle - nur mit Doubles implementiert.
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:Insgesamt fällt am Design der FPU auf, dass die Einheit „FP2” eher schwach mit Ausführungseinheiten ausgestattet ist
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 vpshuf
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.
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:Bei den Caches gibt es eindeutige Angaben: 32 kB L1D- und 512 kB L2-Cache. Das klingt plausibel und entspricht ebenfalls dem, was man von der Cat-Architekturfamilie gewohnt ist.
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... , 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. ...
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.Das *3 sollte hier bedeuten, dass der Befehl nur alle 3 Takte möglich ist. Vielleicht ist das aber auch noch ein fehlerhafter Eintrag.
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
- Mitglied seit
- 08.10.2010
- Beiträge
- 4.949
- Renomée
- 441
- Mein Laptop
- Lenovo T15, Lenovo S540
- Prozessor
- AMD Ryzen 7 3700X
- Mainboard
- MSI X570-A PRO
- Kühlung
- Scythe Kama Angle - passiv
- Speicher
- 32 GB (4x 8 GB) G.Skill TridentZ Neo DDR4-3600 CL16-19-19-39
- Grafikprozessor
- Sapphire Radeon RX 5700 Pulse 8GB PCIe 4.0
- Display
- 27", Lenovo, 2560x1440
- SSD
- 1 TB Gigabyte AORUS M.2 PCIe 4.0 x4 NVMe 1.3
- HDD
- 2 TB WD Caviar Green EADS, NAS QNAP
- Optisches Laufwerk
- Samsung SH-223L
- Gehäuse
- Lian Li PC-B25BF
- Netzteil
- Corsair RM550X ATX Modular (80+Gold) 550 Watt
- Betriebssystem
- Win 10 Pro.
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
☆☆☆☆☆☆
Danke und auch von mir ein herzlich Willkommen im ForumUff. An sich ein netter und informativer Artikel,
Oho, Assemblercode ... wow nicht schlechtWo 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):
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; }
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:
Dresdenboy fielen auf den zweiten Blick hingegen die Wartezyklen der beiden Multiplikatoreinheiten auf. Laut den Einträgen in besagtem Codefragment können diese nur alle fünf Takte Befehle entgegennehmen. Ein einzelner Adder wäre rechnerisch also genug, um im Schnitt alle 2,5 Takte ein Add-Ergebnis zur FMA-Berechnung zur Verfügung zu stellen
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.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.
Ahh sorry ... stimmt, das verwechsle ich immer gerne ... log steht ja auch für "LOGische" Operationen ... willkommen im AbkürzungsjungleAVX hat keine logarithmischen Operationen (und SSE schon gar nicht). "log" steht wohl eher für die bitweisen AND(N)/OR/XOR-Operationen.
Na Du hast es doch verstandenKlingt 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.
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.256-Bit-x86-Befehle werden wie üblich in sogenannte Doubles decodiert, d.h. sie werden in 2 Subinstruktionen (MacroOps) zerlegt
Jo kann man machen - NOCH mehr Zeit wollte ich aber nicht mehr investieren, möglicherweise sind die Einträge ja noch fehlerhaft.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:
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'.
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,
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.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.
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.Die Tabelle auf Seite 3 passt auch nicht. Steamroller und Excavator haben einen Frontend-Durchsatz von 4 Befehlen pro Takt, nicht 2,
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.und die L2-Latenz bei K10 ist AFAIK auch höher (hab aber nichts hier, um das wirklich zu testen).
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.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...
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:Bereits Bulldozer fand ich bei der FPU Performance gegenüber K10 richtig schwach ausgelegt, es zählt nur das was hinten rauskommt!
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: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:
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:Tja .. aber das Codefragment weisst halt darauf hin, denn die gleichen Wartezyklen gibts bei Puma auch
Ja, etwas suboptimal finde ich die Wortwahl trotzdemOpteron schrieb:Außerdem sollte man wissen was gemeint ist. Erstens hab ich den Begriff vorher eingeführt:
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 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 [...]
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/s
Ab 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:Ja bei 2 Threads .. aber nicht für einen Thread,
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: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
Zuletzt bearbeitet:
WindHund
Grand Admiral Special
- Mitglied seit
- 30.01.2008
- Beiträge
- 12.224
- Renomée
- 536
- Standort
- Im wilden Süden (0711)
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- NumberFields@home
- Lieblingsprojekt
- none, try all
- Meine Systeme
- RYZEN R9 3900XT @ ASRock Taichi X570 & ASUS RX Vega64
- BOINC-Statistiken
- Prozessor
- AMD Ryzen 9 5950X
- Mainboard
- ASRock 570X Taichi P5.05 Certified
- Kühlung
- AlphaCool Eisblock XPX, 366x40mm Radiator 6l Brutto m³
- Speicher
- 2x 16 GiB DDR4-3600 CL26 Kingston (Dual Rank, unbuffered ECC)
- Grafikprozessor
- 1x ASRock Radeon RX 6950XT Formula OC 16GByte GDDR6 VRAM
- Display
- SAMSUNG Neo QLED QN92BA 43" up to 4K@144Hz FreeSync PP HDR10+
- SSD
- WD_Black SN850 PCI-Express 4.0 NVME
- HDD
- 3 Stück
- Optisches Laufwerk
- 1x HL-DT-ST BD-RE BH10LS30 SATA2
- Soundkarte
- HD Audio (onboard)
- Gehäuse
- SF-2000 Big Tower
- Netzteil
- Corsair RM1000X (80+ Gold)
- Tastatur
- Habe ich
- Maus
- Han I
- Betriebssystem
- Windows 10 x64 Professional (up to date!)
- Webbrowser
- @Chrome.Google & Edge Chrome
Pb 1: liegt am Hardware nahen Intel CompilerProblem 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.
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
- Antworten
- 12
- Aufrufe
- 3K
- Antworten
- 18
- Aufrufe
- 5K
- Antworten
- 760
- Aufrufe
- 99K
- Antworten
- 111
- Aufrufe
- 17K
- Antworten
- 0
- Aufrufe
- 142K