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 AMD in Zukunft mit 256-Bit-FPU-Pipelines
Opteron
Redaktion
☆☆☆☆☆☆
Ja absolut richtig. Für aktuelle CPUs braucht man kein FP256bit Flag, da sie intern kein 256bit können. Das hast Du echt messerscharf erkannt.Na dann braucht man ja auch kein FP256 Bit, wenn eh alles mit 128-bit Instruktionen besser ist. Richtig?
Klingelts?
Wenn nicht mal weiter ..
Nein, das ist beidemale das gleiche. Beidemal wird eine x86-Instruktion intern in halb so große Teile zerlegt. Das sieht man schön an der Double-Dekodierung, mit der Du anscheinend nichts anzufangen weisst. Anders kann ich mir Dein igonrantes "irrelevant" nicht erklären.Was irrelevant ist. Der entscheidende Punkt ist, dass K8 die Instruktionen tatsächlich aufteilen musste, da nicht alles im selben Takt verarbeitet werden konnte. Für Bulldozer ist das nicht notwendig. Der kann die volle Breite in einem Takt verarbeiten. Das Aufteilen im K8 war also ein anderes als das was du als Aufteilen in Bulldozer verstehst
Das es da jetzt 2 FMACs gibt ist nett --- es erspart Dir aber nicht das Aufsplitten. Eine 256bit Instruktion muss trotzdem in 128bit aufgesplittet werden. In zwei 0,5l Gläser passen je 0,5l was zusammen 1L ergibt, ja, aber um den Liter unterbringen zu können musst Du ihn aufteilen. Das ist bei den CPUs genauso, deswegen hatte ich die Double-Angaben angegeben. Doubles heißt 2 MOps = 2x128bit. Eben zwei 0,5er Gläser, kein 1L Glas.
Dass es jetzt dank der zwei 128bit Pipes in einem Rutsch geht, ist schön für den Durchsatz, Du schaffst Deinen 1L in einem Zug weg, da Du die zwei 0,5er Gläser gleichzeitig / in einem Takt befüllen kannst, das ist wunderbar und spart Zeit, aber das erspart Dir eben nicht die Aufsplittung bzw. die Double-Decodierung.
Das ist der Punkt den Du nicht kapierst, dabei sollte es anhand der Double-Decodierung nun wirklich glasklar sein.
Ist das jetzt verstanden, dass CPU-technisch 2x128bit nicht das gleich wie 1x256 sind?
Ach vorsichtshalber noch ne kleine Übersicht:
Bulldozer:
AVX256-x86 Instruktion -------> Dekoder ------> zwei 128bit MOps -----> Ausführung in den 2 128b FMACs (parallel möglich).
Jaguar:
AVX256-x86 Instruktion -------> Dekoder ------> zwei 128bit MOps -----> Ausführung seriell in den 128 bit ADD/MUL Pipes.
Excavator (oder was auch immer):
AVX256-x86 Instruktion -------> Dekoder ------> 1 256bit MOps -----> Ausführung in einer der 2 256b FMACs
Da sieht man auch, dass Dein Einwurf mit Jaguar nichts bringt. Wenn das so wäre, wie Du es Dir vorstellst, dann hätte man das Flag schon mit BDv1 einführen müssen. Die Dekodierung ist schließlich nachweislich das gleiche (Double) und die AVX128bit Ausführung ist ebenfalls schneller (siehe Zitat im letzten Posting).
Man könnte sich das Flag nun sicher auch sparen und den Compiler Leuten sagen, dass die 15h Chips ab Model xy 256bit Pipes haben, das hätte man früher beim K10 auch machen können. If K8 = 64bit SSE erzeugen, if K10 = 128bit SSE nutzen. Aber vermutlich wollten sies sauber trennen. Wer weiss wie das bei den APUs ausgeht, oder was zukünftige Jaguars machen werden, also bevor man in ~5 Jahren ne ziemlich komplizierte Abfrage basteln muss (If Fam 15h and Model xy or Fam 16h and model z or ....), gibt man die Info eben gleich über ein kleines CPUID Bit mit.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Tolle Kausalschleife. Substanzlos für mich.Ja absolut richtig. Für aktuelle CPUs braucht man kein FP256bit Flag, da sie intern kein 256bit können.
Nein, eben nicht. Eine Instruktion im gleichen Takt oder eine Instruktion in mehreren Takten verarbeiten zu können, ist für mich immer noch ein klarer Unterschied. Offenbar verstehst du diese Thematik nicht. Anders kann ich mir deine sture Haltung nicht erklären. Über das Thema der Aufspaltung der Datenworte in 32-, 64-, 128-bit oder was auch immer, und den daraus resultierenden MicroOps, sind wir doch schon längst hinaus. Dein Rumreiten auf Fastpath Single und Fastpath Double hilft da auch nicht weiter. Das ist doch nur Mittel zum Zweck. Es gibt übrigens auch 128-bit Instruktionen, die FastPath Double sind. Nur so als Denkanstoss.Nein, das ist beidemale das gleiche.
Und eine 128-bit Instruktion muss nicht aufgesplittet werden oder wie? Seit wann unterstützt x86 IEEE 754-2008? Sry, aber du hast einfach keinen Blick für das Gesamtkonstrukt. Die Datenworte werden so oder so aufgesplittet. An welcher Stelle dies in der Pipeline passiert, Decoder, Scheduler oder ALUs, ist letztendlich implementationsspezifisch und hier nicht ausschlaggebend. Ausschlaggebend ist der Durchsatz pro Takt. Das musst du dir anschauen. Alles andere wird dich nicht aus deiner Kausalschleife befreien.Das es da jetzt 2 FMACs gibt ist nett --- es erspart Dir aber nicht das Aufsplitten. Eine 256bit Instruktion muss trotzdem in 128bit aufgesplittet werden.
Deine Romane hättest du dir auch sparen können. Dass es hardwareseitig Unterschiede gibt, stand doch gar nicht zur Debatte. Das ist für die Hardwareingenieure natürlich wichtig. Du erzählst uns da keine Neuigkeiten. CPUID hingegen richtet sich an Softwareentwickler. Und aus softwareseitiger Sicht ist diese interne Verarbeitung belanglos. Ich sehe zumindest keinen konkreten Nutzen von deren Kenntnis. Und du hast auch noch keine Argumente gebracht, die das ändern würden. Das ist der Punkt, den du anscheinend nicht kapierst oder nicht kapieren willst.Dass es jetzt dank der zwei 128bit Pipes in einem Rutsch geht, ist schön für den Durchsatz, Du schaffst Deinen 1L in einem Zug weg, da Du die zwei 0,5er Gläser gleichzeitig / in einem Takt befüllen kannst, das ist wunderbar und spart Zeit, aber das erspart Dir eben nicht die Aufsplittung bzw. die Double-Decodierung.
Das ist der Punkt den Du nicht kapierst, dabei sollte es anhand der Double-Decodierung nun wirklich glasklar sein.
Nein. Auch bdver1 konnte 256-bit schon in einem Takt. Es gab keine Notwendigkeit, zu differenzieren. Erst Jaguar ändert das.Wenn das so wäre, wie Du es Dir vorstellst, dann hätte man das Flag schon mit BDv1 einführen müssen.
Zuletzt bearbeitet:
sompe
Grand Admiral Special
- Mitglied seit
- 09.02.2009
- Beiträge
- 14.439
- Renomée
- 2.000
- Mein Laptop
- Dell G5 15 SE 5505 Eclipse Black
- Prozessor
- AMD Ryzen 9 3950X
- Mainboard
- MSI MPG X570 GAMING PRO CARBON WIFI
- Kühlung
- Wasserkühlung
- Speicher
- 4x 16 GB G.Skill Trident Z RGB, DDR4-3200, CL14
- Grafikprozessor
- AMD Radeon RX 6900 XT
- Display
- 1x 32" LG 32UD89-W + 1x 24" Dell Ultrasharp 2405FPW
- SSD
- Samsung SSD 980 PRO 1TB, Crucial MX500 500GB, Intel 600p 512GB, Intel 600p 1TB
- HDD
- Western Digital WD Red 2 & 3TB
- Optisches Laufwerk
- LG GGC-H20L
- Soundkarte
- onboard
- Gehäuse
- Thermaltake Armor
- Netzteil
- be quiet! Dark Power Pro 11 1000W
- Betriebssystem
- Windows 10 Professional, Windows 7 Professional 64 Bit, Ubuntu 20.04 LTS
- Webbrowser
- Firefox
@gruffi
Es ist aber ein Unterschied ob sie als ganzes innerhalb des Taktes verarbeitet wird oder ob sie dafür zerhackt und die beiden Teile parallel verarbeitet werden. Beim ersten werden 256 Bit verarbeitet und beim anderen 2x 128Bit im selben Takt.
Es ist aber ein Unterschied ob sie als ganzes innerhalb des Taktes verarbeitet wird oder ob sie dafür zerhackt und die beiden Teile parallel verarbeitet werden. Beim ersten werden 256 Bit verarbeitet und beim anderen 2x 128Bit im selben Takt.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Nochmal, darum geht es doch überhaupt nicht. Der Durchsatz pro Takt ist der gleiche. Verrate mir doch mal, welchen Unterschied das auf Softwareseite macht?Es ist aber ein Unterschied ob sie als ganzes innerhalb des Taktes verarbeitet wird oder ob sie dafür zerhackt und die beiden Teile parallel verarbeitet werden. Beim ersten werden 256 Bit verarbeitet und beim anderen 2x 128Bit im selben Takt.
Der Durchsatz pro Takt ist nicht der Gleiche, laut Benchmarks, die in diesem Thread erwähnt wurden.Der Durchsatz pro Takt ist der gleiche. Verrate mir doch mal, welchen Unterschied das auf Softwareseite macht?
Der Durchsatz in den FPU-Pipelines ist der Gleiche aber der Gesamtdurchsatz ist nicht der Gleiche, weil durch die Aufsplittung in den Decodern offenbar ca. 3 Prozent performanceverlust entsteht, wie die Benchmarks zeigen.
Zuletzt bearbeitet:
BDv1: avx 256 (Durchsatz 1/Takt pro Modul - 0.5/Takt pro Kern)
BDv1: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 256 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
(X durch neue Architektur mit 256Bit Pipelines ersetzen)
Macht für mich also einen großen Unterschied im Durchsatz bei den neuen breiteren Pipelines wenn man mit 256Bit SIMD Instruktionen rechnet.
Die Latenz ist da auch erst mal zweitrangig, vor allem da durch die Teilung der FPU zwischen 2 Kernen sowieso ein zusätzlicher Wartezyklus entstehen kann.
Gerade für die Software ist das eben auch ein riesiger Unterschied ob nun AVX 256 doppelt so schnell ist wie AVX 128 oder eben nicht, bzw. sogar ein paar Prozent langsamer.
Warum du hier auf den Floating Point Standard hinweist verstehe ich auch nicht ganz. Bei 128Bit Recheneinheiten werden eben z.b. 2 64Bit Berechnungen durchgeführt und bei 256 Bit SIMD eben z.B. 4 mal 64 Bit. Heißt also bei letzterem gibt es einen höheren Durchsatz, den du hier nicht sehen willst?
BDv1: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 256 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
(X durch neue Architektur mit 256Bit Pipelines ersetzen)
Macht für mich also einen großen Unterschied im Durchsatz bei den neuen breiteren Pipelines wenn man mit 256Bit SIMD Instruktionen rechnet.
Die Latenz ist da auch erst mal zweitrangig, vor allem da durch die Teilung der FPU zwischen 2 Kernen sowieso ein zusätzlicher Wartezyklus entstehen kann.
Gerade für die Software ist das eben auch ein riesiger Unterschied ob nun AVX 256 doppelt so schnell ist wie AVX 128 oder eben nicht, bzw. sogar ein paar Prozent langsamer.
Warum du hier auf den Floating Point Standard hinweist verstehe ich auch nicht ganz. Bei 128Bit Recheneinheiten werden eben z.b. 2 64Bit Berechnungen durchgeführt und bei 256 Bit SIMD eben z.B. 4 mal 64 Bit. Heißt also bei letzterem gibt es einen höheren Durchsatz, den du hier nicht sehen willst?
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Doch, theoretisch ist er erst mal gleich. Ausserdem ist es für mich ziemlich spekulativ, woher einige wenige Prozent Unterschied kommen. Das kann auch einfach nur eine Softwaregeschichte sein oder ist auf andere Limitierungen des Designs zurückzuführen. Wie gesagt, das interne Design wurde einst für SSE5 entwickelt. Vielleicht hat man irgendwo noch Defizite beim Balancing. Und ob man nun wegen 2-3% in irgendwelchen synthetischen Tests extra ein solches Bit einführt, ist doch sehr fraglich. Und warum erst jetzt, wenn das schon über 2 Jahre oder vielleicht noch länger bekannt ist? Wie gesagt, aufgrund von Jaguar wäre das Bit deutlich plausibler. Zum einen, weil die Auswirkungen da deutlich gravierender sein können. Und zum anderen, weil es eben die gleiche Geschichte wie mit K8 ist. Für die volle Datenbreite der SIMD Pipeline braucht man mehr als einen Takt.Der Durchsatz pro Takt ist nicht der Gleiche
Keine Ahnung, was uns diese Übersicht sagen soll. Natürlich hätte eine breitere FPU mehr Durchsatz. Liegt nun mal in der Sache der Natur. Das ändert aber nichts am aktuellen Durchsatz, um den es ging. Egal wie die interne Verarbeitung konkret ausschaut. Wenn's um Compiler geht, die haben eh für jeden Kern bzw jede Architektur spezifische Infos zur Codeoptimierung. Wie viele ALUs, welche Datenbreite, Latenzen usw. Das wird auch in Zukunft so sein und daran ändert auch das FP256 Bit nichts.BDv1: avx 256 (Durchsatz 1/Takt pro Modul - 0.5/Takt pro Kern)
BDv1: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 256 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
(X durch neue Architektur mit 256Bit Pipelines ersetzen)
Weil es sowieso keine 128-bit oder 256-bit FP Operationen gibt. Bzw unterstützt erst IEEE 754-2008 128-bit FP Operationen. x86 Prozessoren unterstützen bisher aber maximal 64-bit FP Operationen (x87 mal aussen vor gelassen). Dh, intern wird irgendwann sowieso alles auf 32-bit (SP) bzw 64-bit (DP) zerstückelt. Egal ob die Eingabepuffer als 1x 256-bit oder 2x 128-bit behandelt werden.Warum du hier auf den Floating Point Standard hinweist verstehe ich auch nicht ganz.
Zuletzt bearbeitet:
sompe
Grand Admiral Special
- Mitglied seit
- 09.02.2009
- Beiträge
- 14.439
- Renomée
- 2.000
- Mein Laptop
- Dell G5 15 SE 5505 Eclipse Black
- Prozessor
- AMD Ryzen 9 3950X
- Mainboard
- MSI MPG X570 GAMING PRO CARBON WIFI
- Kühlung
- Wasserkühlung
- Speicher
- 4x 16 GB G.Skill Trident Z RGB, DDR4-3200, CL14
- Grafikprozessor
- AMD Radeon RX 6900 XT
- Display
- 1x 32" LG 32UD89-W + 1x 24" Dell Ultrasharp 2405FPW
- SSD
- Samsung SSD 980 PRO 1TB, Crucial MX500 500GB, Intel 600p 512GB, Intel 600p 1TB
- HDD
- Western Digital WD Red 2 & 3TB
- Optisches Laufwerk
- LG GGC-H20L
- Soundkarte
- onboard
- Gehäuse
- Thermaltake Armor
- Netzteil
- be quiet! Dark Power Pro 11 1000W
- Betriebssystem
- Windows 10 Professional, Windows 7 Professional 64 Bit, Ubuntu 20.04 LTS
- Webbrowser
- Firefox
So wie ich es mitbekommen hatte ging es die ganze Zeit darum ob der 256 Bit Code in einem Stück schlucken kann oder in Häpchen verarbeitet. Die Relevanz für die Software dürfte recht einfach sein. Schnappt sich der 256 Bit Code beide FPU Teile des Moduls ist für den zweiten Kern des Moduls erstmal Feierabend mit FPU Zugriffen. Des weiteren dürfte die Aufspaltung der Befehle letztendlich auch Zeit und einen gewissen Rechenaufwand kosten. Daher kommt vermutlich u.A. auch der Leistungsverlußt bei 256 Bit Code.Nochmal, darum geht es doch überhaupt nicht. Der Durchsatz pro Takt ist der gleiche. Verrate mir doch mal, welchen Unterschied das auf Softwareseite macht?
Der Unterschied für die Software ist also mindestens ein gewisser Performanceverlußt.
Deine Aussage zu den FP-Formaten ist mir hier immer noch nicht schlüssig, da meiner Meinung nach hier niemand davon ausging das mit 256 Bit breiten FP Zahlen gerechnet wird.
Das Bit sagt laut Tabelle aus: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Bulldozer hat keine 256 Bit Pipeline. Jaguar erst recht nicht.
"... rather than decomposing them into internal 128 Bit suboperations."
Also genau dem was Bulldozer im Moment machen muss. Problem ist dabei im Moment ja auch noch das der Dispatch auf 4 Makro Ops beschränkt ist, also mit einer double Dekodierung der x86-Durchsatz des ganzen Modules negativ beeinflusst wird.
Damit ist das neue Bit auch weder für Bulldozer noch für Jaguar geeignet, ich weiß ehrlich gesagt nicht wie man das hier rauslesen kann.
Und die Frage ist doch woher die Compiler ihre Infos bekommen. Vlt. aus den CPUID Bits? Ansonsten könnte man diese Register ja auch gleich sein lassen, braucht ja keiner.
Dazu gibt es neben den Instruktionsbits auch diese Performance Bits wie man an deren Namen schon sehen kann. Ob die genutzt werden ist natürlich Sache der jeweiligen Compiler Entwickler.
Das Bit sagt laut Tabelle aus: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Bulldozer hat keine 256 Bit Pipeline. Jaguar erst recht nicht.
"... rather than decomposing them into internal 128 Bit suboperations."
Also genau dem was Bulldozer im Moment machen muss. Problem ist dabei im Moment ja auch noch das der Dispatch auf 4 Makro Ops beschränkt ist, also mit einer double Dekodierung der x86-Durchsatz des ganzen Modules negativ beeinflusst wird.
Damit ist das neue Bit auch weder für Bulldozer noch für Jaguar geeignet, ich weiß ehrlich gesagt nicht wie man das hier rauslesen kann.
Und die Frage ist doch woher die Compiler ihre Infos bekommen. Vlt. aus den CPUID Bits? Ansonsten könnte man diese Register ja auch gleich sein lassen, braucht ja keiner.
Dazu gibt es neben den Instruktionsbits auch diese Performance Bits wie man an deren Namen schon sehen kann. Ob die genutzt werden ist natürlich Sache der jeweiligen Compiler Entwickler.
ELKINATOR
Gesperrt
wäre es nicht auch möglich das man in zukunft 3 128bit FPUs hat?
jeder kern hat seine eigene und die in der mitte wird geteilt.
jeder kern hat seine eigene und die in der mitte wird geteilt.
Crashtest
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 11.11.2008
- Beiträge
- 9.284
- Renomée
- 1.415
- Standort
- Leipzig
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- Collatz, yoyo, radac
- Lieblingsprojekt
- yoyo
- Meine Systeme
- Ryzen: 2x1600, 5x1700, 1x2700,1x3600, 1x5600X; EPYC 7V12 und Kleinzeuch
- BOINC-Statistiken
- Folding@Home-Statistiken
- Mein Laptop
- Lenovo IdeaPad 5 14ALC05
- Prozessor
- Ryzen 7950X / Ryzen 4750G
- Mainboard
- ASRock B650M PGRT / X570D4U
- Kühlung
- be quiet! Dark Rock Pro4 / Pure Rock Slim 2
- Speicher
- 64GB DDR5-5600 G Skill F5-5600J3036D16G / 32 GB DDR4-3200 ECC
- Grafikprozessor
- Raphael IGP / ASpeed AST-2500
- Display
- 27" Samsung LF27T450F
- SSD
- KINGSTON SNVS2000G
- HDD
- - / 8x Seagate IronWolf Pro 20TB
- Optisches Laufwerk
- 1x B.Ray - LG BD-RE BH16NS55
- Soundkarte
- onboard HD?
- Gehäuse
- zu kleines für die GPU
- Netzteil
- be quiet! Pure Power 11 400W / dito
- Tastatur
- CHERRY SECURE BOARD 1.0
- Maus
- Logitech RX250
- Betriebssystem
- Windows 10 19045.4355 / Server 20348.2402
- Webbrowser
- Edge 124.0.2478.51
- Verschiedenes
- U320 SCSI-Controller !!!!
- Internetanbindung
- ▼1000 MBit ▲82 MBit
Pro Modul 2x256 Bit wär schon ok, besser wäre mit Möglichkeit:
- 1x512Bit + warten
- 1x255Bit + 1x256Bit
- 3x128Bit + 1x128Bit
sodass dynamisch die 2 256Bit Einheiten auf/zugeteilt werden könnten
- 1x512Bit + warten
- 1x255Bit + 1x256Bit
- 3x128Bit + 1x128Bit
sodass dynamisch die 2 256Bit Einheiten auf/zugeteilt werden könnten
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Nein. Es ging darum, worauf das CPUID Bit zurückzuführen ist. Opteron sagt in seinem Artikel, dass das die quasi Bestätigung für zukünftige 256-bit FMACs ist. Ich sage, dass das noch lange nicht so sein muss bzw nicht in einem solchen Zusammenhang stehen muss. Es kann auch lediglich für Fälle wie Jaguar eingeführt worden sein. Was natürlich trotzdem nicht ausschliesst, dass die FMACs in zukünftigen Designs aufgebohrt werden.So wie ich es mitbekommen hatte ging es die ganze Zeit darum ob der 256 Bit Code in einem Stück schlucken kann oder in Häpchen verarbeitet.
Das sehe ich aber nicht als Problem, welches man mit einem CPUID Bit umgehen müsste. Das ist nun mal die Konsequenz eines solchen flexiblen FPU Designs. Was wäre denn die Alternative? Zwei 256-bit FMACs, damit bei einer 256-bit Instruktion nicht gleich sämtliche FPU Ressourcen blockiert sind, die FPU dafür aber die meiste Zeit nur halb ausgelastet wird? Ist das besser? Ich denke nicht. Die paar wenigen Prozent Unterschied, die in den synthetischen Tests gemessen wurden, sind mMn zu vernachlässigen. Das erfordert mehr Balancing auf Hardwareebene und generell angepasste Codegenerierung und nicht irgendwelche spezifischen Softwarepfade entsprechend einem CPUID Bit.Daher kommt vermutlich u.A. auch der Leistungsverlußt bei 256 Bit Code.
Da steht auch nichts von 256-bit Pipeline. Auf Deutsch steht da, dass die internen Operationen und Pipelines die Ausführung von Instruktionen mit voller AVX Breite unterstützen, also 256-bit. Wie diese 256-bit erreicht werden, ist doch erst mal nebensächlich. Und der zweite Teil ist eben genau das, was K8 schon gemacht hat und auch Jaguar jetzt macht. Die Instruktionen in zwei Datenpakete zu zerstückeln, die dann in verschiedenen Takten verarbeitet werden. Ich kann aber auch dir nur nochmal sagen, in diese Formulierungen nicht zu viel hinein zu interpretieren. Es ist lediglich C&P und als das FP128 Bit formuliert wurde, gab es noch keinen Bulldozer. Was die Grundlage für das FP256 Bit ist, kann im Moment nur AMD beantworten. Jaguar erscheint mir im Moment aber wie gesagt plausibler als hypothetische 256-bit FMACs.Das Bit sagt laut Tabelle aus: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Bulldozer hat keine 256 Bit Pipeline. Jaguar erst recht nicht.
"... rather than decomposing them into internal 128 Bit suboperations."
Also genau dem was Bulldozer im Moment machen muss.
Wäre gar keine so schlechte Idee. Eigentlich ist 128-bit Verarbeitung ja auch zu bevorzugen. Eben weil uns SSE wohl noch einige Zeit erhalten bleibt und weil mit reinen 256-bit FMACs die Hälfte der Rechenkapazitäten oft brach liegt. 4-fach FP32 Vektoren sind gängige Konstrukte, zB für Koordinaten und Farbinformationen in Grafikanwendungen wie Spielen. Also auch 256-bit FMACs müssten flexibel für 128-bit Verarbeitung gestaltet werden, damit die Effizienz nicht leidet.wäre es nicht auch möglich das man in zukunft 3 128bit FPUs hat?
Zuletzt bearbeitet:
ELKINATOR
Gesperrt
1x512Bit gibts bei AVX leider noch nicht und bei 4x128Bit steigt eben wieder der Hardwareaufwand durch die 2 zusätzlichen Ports. Da man jetzt allerdings auch schon 4 SIMD Operationen alleine für FP dekodieren müsste, stellt sich dabei die Frage ob die Dekoder überhaupt noch genug Durchsatz bringen. Es gibt ja schließlich auch noch andere Operationen die neben dem FP-Instruktionen ausgeführt werden wollen.
Bei Steamroller wechselt man ja nun auch von ursprünglich 4 auf nur noch 3 Ports für die SIMD Pipelines. Der Sinn von den Shared Pipelines ist ja, das jeder Kern bei Bedarf auf die gesamten Ressourcen des Moduls zurückgreifen kann. Da dürfte in der Tat bei 2-3 Ports Schluss sein selbst bei 2 seperaten Decodern. (Wenn man von 2-fach Dekodern ausgeht ist alles über 2 Ports sowieso ziemlicher humbug.)
Wenn man es für den maximalen Durchsatz beider Kerne auslegt könnte man in der Tat auch wieder zum klassischen Kerndesign mit 2 seperaten FPUs zurück wechseln. Aber wie Tests zeigen erreicht man ja auch so Skalierungswerte von annähernd 80% von daher scheinen 2 shared FP-Ports durchaus ausreichend um ein Modul auszulasten.
Der nächste Schritt um mehr Performance herauszuholen ist dann eben von 128 auf 256 Bit Breite.
(Abgesehen davon ist die 2fach Dekodierung sowieso mehr als unwahrscheinlich da der Int-Zweig auf eine maximale 4fach Ausführung ausgelegt ist, also würde man sich hier wieder langsamer machen als man vorher war.)
Und noch mal: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Die Breite der internen Pipeline ist bei BD nicht 256 Bit also können die Instruktionen auch nicht so ausgeführt werden. Das "Operations" bezieht sich übrigens auch auf makro-Op Ebene, eben weil von intern gesprochen wird. Das zeigt sich dann auch noch mal im 2. Satz.
Wenn das Bit für BDv1 hätte gelten sollen, wären sie damit jetzt eh reichlich spät dran.
Bei Steamroller wechselt man ja nun auch von ursprünglich 4 auf nur noch 3 Ports für die SIMD Pipelines. Der Sinn von den Shared Pipelines ist ja, das jeder Kern bei Bedarf auf die gesamten Ressourcen des Moduls zurückgreifen kann. Da dürfte in der Tat bei 2-3 Ports Schluss sein selbst bei 2 seperaten Decodern. (Wenn man von 2-fach Dekodern ausgeht ist alles über 2 Ports sowieso ziemlicher humbug.)
Wenn man es für den maximalen Durchsatz beider Kerne auslegt könnte man in der Tat auch wieder zum klassischen Kerndesign mit 2 seperaten FPUs zurück wechseln. Aber wie Tests zeigen erreicht man ja auch so Skalierungswerte von annähernd 80% von daher scheinen 2 shared FP-Ports durchaus ausreichend um ein Modul auszulasten.
Der nächste Schritt um mehr Performance herauszuholen ist dann eben von 128 auf 256 Bit Breite.
(Abgesehen davon ist die 2fach Dekodierung sowieso mehr als unwahrscheinlich da der Int-Zweig auf eine maximale 4fach Ausführung ausgelegt ist, also würde man sich hier wieder langsamer machen als man vorher war.)
Und noch mal: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Die Breite der internen Pipeline ist bei BD nicht 256 Bit also können die Instruktionen auch nicht so ausgeführt werden. Das "Operations" bezieht sich übrigens auch auf makro-Op Ebene, eben weil von intern gesprochen wird. Das zeigt sich dann auch noch mal im 2. Satz.
Wenn das Bit für BDv1 hätte gelten sollen, wären sie damit jetzt eh reichlich spät dran.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Ich denke nicht, dass man aus einem 4-fach Decoder zwei 2-fach Decoder macht. Damit hat man ja nichts gewonnen. Ich gehe von mindestens zwei 3-fach Decodern aus. Eventuell werden es auch zwei 4-fach Decoder.
Mit Steamroller wird doch die Decoderbandbreite erhöht und zusätzlich fällt eine Pipe in der FPU weg. Ein dritter 128-bit FMAC sollte also kein Problem sein. Selbst ein vierter ist machbar.Da man jetzt allerdings auch schon 4 SIMD Operationen alleine für FP dekodieren müsste, stellt sich dabei die Frage ob die Dekoder überhaupt noch genug Durchsatz bringen.
Da steht auch nichts von 256-bit Operationen. Wie gesagt, am Ende wird eh alles auf FP32 und FP64 Operationen heruntergebrochen. Der springende Punkt bei der Formulierung ist "full-width". Und das ist der Fall. Ob nun als 1x 256-bit oder 2x 128-bit, spielt am Ende keine Rolle. Und "operations" ist Operation, also eine ganz allgemeine Umschreibung für ADD, MUL, etc.Und noch mal: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Die Breite der internen Pipeline ist bei BD nicht 256 Bit also können die Instruktionen auch nicht so ausgeführt werden.
Ich sage es nochmal:
Ich kann aber auch dir nur nochmal sagen, in diese Formulierungen nicht zu viel hinein zu interpretieren. Es ist lediglich C&P und als das FP128 Bit formuliert wurde, gab es noch keinen Bulldozer.
ONH
Grand Admiral Special
Ich sage es nochmal:
Dennoch stellt sich die Frage, wieso braucht es in zukünftigen Prozessoren ein FP256 bit in der CPUID. Wenn sich da "nichts" gegenüber von Bulldozer oder Jaguar ändern wird, also wieso soll es 2x 126 bit sein.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Es ist eben die gleiche Geschichte wie mit K8 -> K10. Maximal die chronologische Reihenfolge ist eine andere. K8 und K10 haben jedenfalls die 128-bit SSE Pipeline unterstützt. K8 konnte 128-bit Instruktionen aber nicht in einem Takt verarbeiten, weil die FPU lediglich 64-bit breit war. Erst mit K10 wurde die FPU auf 128-bit verbreitert. Vergleichbares sehen wir nun bei Jaguar und Bulldozer mit AVX. Beide Architekturen unterstützen die 256-bit AVX Pipeline. Aber nur Bulldozer ist in der Lage, entsprechende Instruktionen in einem Takt zu verarbeiten. Ob intern 1x 256-bit oder 2x 128-bit ist wie gesagt erst mal nebensächlich. Da Jaguar aber lediglich eine 128-bit FPU besitzt, braucht der genauso wie K8 mehrere Takte.Dennoch stellt sich die Frage, wieso braucht es in zukünftigen Prozessoren ein FP256 bit in der CPUID.
Also ich bin mir zu 99,9% sicher, dass das FP256 Bit für Fälle wie Jaguar geschaffen wurde. Das ist relativ eindeutig. Wie ich zuvor schon sagte, ob es eventuell auch zusätzlich für andere Fälle gilt, wie Bulldozer, hängt von weiteren Faktoren ab. Durch die Modulbauweise und die geteilten Ressourcen für zwei Threads ergeben sich weitere Betrachtungsweisen. ZB nicht nur pro Takt pro Pipeline, sondern auch pro Takt pro Thread. Das kann uns letztendlich nur AMD beantworten.
Opteron
Redaktion
☆☆☆☆☆☆
Ach ich langweile Dich mal wieder mit ein paar nutzlosen Kommentaren, bin gerade gut aufgelegt
Oder anders gesagt, Du übersiehst da den Begriff "internal". Internal mein MOps (anders macht es keinen Sinn, max. gibts 64bit DP-Werte und die wurden schon beim K8 in "full-width" übertragen) und davon brauchst Du beim BD, wie beim Jaguar nunmal 2. Eine einzige AVX256 Anweisung musst Du in je 2 128er aufsplitten, wobei Du die Rechen-Opteration sinnloserweise durch das Aufsplitten kopieren musst.
Das ist bei BD leider nicht der Fall... die volle Bandbreite hast Du nur aus externer Sicht und das auch nur bei nem einzigen Tasks auf dem Modul.
Das ganze Bit für Jaguar macht keinen Sinn.
Für Jaguar müsste es auf Null gesetzt werden - wir sind uns ja einig, dass Jaguar keine full-width hat - allerdings steht es aktuell bei allen K10 und BD-Varianten auch schon auf 0. Man kann BD und Jaguar also nicht anhand des Bits unterscheiden, obwohl BD laut Deiner Auslegung ja full-width hätte. Natürlich könnte man zur Unterscheidung noch die restlichen CPUID-Bits abfragen, aber wenn man die auch noch benützen müsste, könnte man sich das FP256 Bit gleich ganz sparen.
Oder meinst Du, dass Jaguar das Bit auf 1 setzen wird? Dann wäre der Beschreibungsname im PDF arg irreführend. Dafür hätten sie es dann AVX128, No256 oder sonstwas nennen müssen.
Warten wirs mal ab. Neue Argumente gibts keine mehr, bzw. sie werden ignoriert, aber CPUID-Dumps der Kabinis sind nicht mehr weit entfernt.
Ja, aber es macht nen "kleine" Unterschied, ob Du ein 256er-Paket in 4 Teile zerlegst, oder 2x128 in 2.am Ende wird eh alles auf FP32 und FP64 Operationen heruntergebrochen.
Oder anders gesagt, Du übersiehst da den Begriff "internal". Internal mein MOps (anders macht es keinen Sinn, max. gibts 64bit DP-Werte und die wurden schon beim K8 in "full-width" übertragen) und davon brauchst Du beim BD, wie beim Jaguar nunmal 2. Eine einzige AVX256 Anweisung musst Du in je 2 128er aufsplitten, wobei Du die Rechen-Opteration sinnloserweise durch das Aufsplitten kopieren musst.
Jo full-width internal.Der springende Punkt bei der Formulierung ist "full-width".
Das ist bei BD leider nicht der Fall... die volle Bandbreite hast Du nur aus externer Sicht und das auch nur bei nem einzigen Tasks auf dem Modul.
Das ganze Bit für Jaguar macht keinen Sinn.
Für Jaguar müsste es auf Null gesetzt werden - wir sind uns ja einig, dass Jaguar keine full-width hat - allerdings steht es aktuell bei allen K10 und BD-Varianten auch schon auf 0. Man kann BD und Jaguar also nicht anhand des Bits unterscheiden, obwohl BD laut Deiner Auslegung ja full-width hätte. Natürlich könnte man zur Unterscheidung noch die restlichen CPUID-Bits abfragen, aber wenn man die auch noch benützen müsste, könnte man sich das FP256 Bit gleich ganz sparen.
Oder meinst Du, dass Jaguar das Bit auf 1 setzen wird? Dann wäre der Beschreibungsname im PDF arg irreführend. Dafür hätten sie es dann AVX128, No256 oder sonstwas nennen müssen.
Und ich bin mir 100% sicher, dass Du zu 99,9% falsch liegstAlso ich bin mir zu 99,9% sicher, dass das FP256 Bit für Fälle wie Jaguar geschaffen wurde.
Warten wirs mal ab. Neue Argumente gibts keine mehr, bzw. sie werden ignoriert, aber CPUID-Dumps der Kabinis sind nicht mehr weit entfernt.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Aus Softwaresicht nicht wirklich. Das nennt sich Hardwareparallelität.Ja, aber es macht nen "kleine" Unterschied, ob Du ein 256er-Paket in 4 Teile zerlegst, oder 2x128 in 2.
Auch für dich nochmal:Oder anders gesagt, Du übersiehst da den Begriff "internal".
Mal schauen, wie oft ich das wiederholen muss, bis es jeder versteht.Ich kann aber auch dir nur nochmal sagen, in diese Formulierungen nicht zu viel hinein zu interpretieren. Es ist lediglich C&P und als das FP128 Bit formuliert wurde, gab es noch keinen Bulldozer.
Doch. Es sind intern insgesamt 256-bit, also die volle Breite der AVX Pipeline. Wie dies organisiert wird, ist wie gesagt erst mal nebensächlich.Jo full-width internal.
Das ist bei BD leider nicht der Fall...
Natürlich, gerade dafür. Bisher unterstützt nur Bulldozer AVX. Und der kann AVX Instruktionen in einem Takt. Mit Jaguar ändert sich das nun. Der kann AVX Instruktionen nicht in einem Takt und muss diese zerstückeln, um sie in mehreren Takten zu verarbeiten. Also wird ein Bit zur Differenzierung sinnvoll. Nach deiner Argumentation wäre ein solches Bit aktuell nicht notwendig, da es immer nur einen Zustand hätte. Und sich dann auf irgendwelche hypothetischen 256-bit FMACs in Zukunft zu beziehen, ist äusserst spekulativ.Das ganze Bit für Jaguar macht keinen Sinn.
Das liegt an zwei Sachen. Erstens, bisher nicht genutzte Bits stehen natürlich immer erst mal auf 0 per default. Und zweitens, man ändert nicht einfach die Logik solcher Bits. Man versucht konsistent zu bleiben. Wie ich schon sagte, die chronologische Reihenfolge ist eine andere. Bei K8 -> K10 kam zuerst die halbe Hardwarebreite und dann die volle. Mit Bulldozer -> Jaguar ist es nun umgekehrt. Zuerst kam die volle Hardwarebreite und dann die halbe.allerdings steht es aktuell bei allen K10 und BD-Varianten auch schon auf 0.
Opteron
Redaktion
☆☆☆☆☆☆
Ja und? Das ändert nichts am Problem der 0en bei den BDs. Wie willst Du das denn beheben, dass Jaguar und BDv1v2 gleich behandelt werden? Willst DU ein µCode-Update verschicken, dass bei den BDs das Bit nachträglich auf 1 ändert?Mit Bulldozer -> Jaguar ist es nun umgekehrt. Zuerst kam die volle Hardwarebreite und dann die halbe. Bisher nicht genutzte Bits stehen natürlich immer erst mal auf 0 per default.
Eben, das Bit wird aus Konsistenzgründen nicht geändert, ergo bleiben die aktuellen BDs bei FP256=0 und irgendwann demnächst wirds ne CPU mit FP256=1 geben.Erstens, man ändert nicht einfach die Logik solcher Bits. Man versucht konsistent zu bleiben.
Und das wird kein Jaguar sein
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Nein. Ist es denn ein Problem, wenn der aktuelle Bulldozer und Jaguar gleich behandelt werden? Ich denke nicht. Bulldozer erleidet mit 128-bit Instruktionen keinen Leistungsverlust. Umgekehrt kann man das für Jaguar und 256-bit Instruktionen nicht einfach so sagen. Für Bulldozer dürfte es im Moment ziemlich egal sein, auf welchem Wert das Bit steht. Egel ob man softwareseitig für 128-bit oder 256-bit AVX Instruktionen optimiert, Bulldozer sollte in beiden Fällen ähnlich performen.Ja und? Das ändert nichts am Problem der 0en bei den BDs. Wie willst Du das denn beheben, dass Jaguar und BDv1v2 gleich behandelt werden? Willst DU ein µCode-Update verschicken, dass bei den BDs das Bit nachträglich auf 1 ändert?
Das hat auch keiner behauptet. Du scheinst den Sinn und die Logik solcher Bits immer noch nicht verstanden zu haben. Man macht solche Bits nicht, damit man sie auf 1 setzen kann. Man macht solche Bits, um zwischen zwei Zuständen bzw Optionen unterscheiden zu können. Und genau das ist bei Jaguar der Fall, da der hardwareseitig nicht die volle Breite der AVX Pipeline unterstützt. Bulldozer hingegen tut das schon. Welcher Zustand dann mit 0 und 1 definiert wird, ist nebensächlich. Eine alte Faustregel der Programmierung lautet, Default-Zustände sollten mit 0 definiert werden.Eben, das Bit wird aus Konsistenzgründen nicht geändert, ergo bleiben die aktuellen BDs bei FP256=0 und irgendwann demnächst wirds ne CPU mit FP256=1 geben.
Und das wird kein Jaguar sein
Vielleicht glaubst du wenigstens einmal jemandem etwas, der sich mit dieser Thematik etwas besser auskennt als du.
Opteron
Redaktion
☆☆☆☆☆☆
Na wenn Du zw. BD und Jaguar nicht unterscheidest, wozu brauchst Du das Bit dann überhaupt?Nein. Ist es denn ein Problem, wenn der aktuelle Bulldozer und Jaguar gleich behandelt werden? Ich denke nicht.
Ich glaub Dir immer gerne -- solange es nen Sinn ergibtVielleicht glaubst du wenigstens einmal jemandem etwas, der sich mit dieser Thematik etwas besser auskennt als du.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Du sprachst davon, wenn das Bit auf 0 gesetzt ist. Darauf bezog sich auch meine Antwort. Ich habe nicht gesagt, dass man beide grundsätzlich gleich behandeln soll. Bei zukünftigen Bulldozern könnte das Bit auf 1 gesetzt sein, trotz 128-bit FMACs. Jaguar hingegen bleibt auf 0. Dann sind beide natürlich zu unterscheiden.Na wenn Du zw. BD und Jaguar nicht unterscheidest, wozu brauchst Du das Bit dann überhaupt?
Opteron
Redaktion
☆☆☆☆☆☆
Und wieviel Sinn macht es dann, bei der einen 128er FMAC FPU das FP256 Flag zu setzen, und bei der andern nicht? Wo soll dann Deiner Meinung nach der Unterschied sein, der das unterschiedliche Setzen rechtfertigt?Ich habe nicht gesagt, dass man beide grundsätzlich gleich behandeln soll. Bei zukünftigen Bulldozern könnte das Bit auf 1 gesetzt sein, trotz 128-bit FMACs. Jaguar hingegen bleibt auf 0. Dann sind beide natürlich zu unterscheiden.
Waren die aktuellen BDs einfach zu früh dran und haben "Pech gehabt"?
Da widersprichst Du doch Dir selbst, wenn Du früher schriebst:
Einmal 128bit = 0 und einmal = 1 ist ne Änderung der Logik.man ändert nicht einfach die Logik solcher Bits. Man versucht konsistent zu bleiben.
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 2K
- Antworten
- 0
- Aufrufe
- 954
- Antworten
- 0
- Aufrufe
- 1K
- Antworten
- 1
- Aufrufe
- 1K