Haben moderne CPUs eine eigene FPU?
-
Ja, bei Maschienen ohne Bedarf an Gleitkommazahlen ist das Verschwendung. Ich habe die Frage auch unsauber formuliert. Die CPUs die mich interessieren sind die 'gängigen' desktop CPUs (also Intels i3, i5, i7 und AMD äquivalente).
Die Aussage zu den Registern ist natürlich vollkommen richtig, daran habe ich garnicht gedacht!
Der ursprüngliche Grund warum ich frage ist der, dass ich gelesen habe, dass CPUs zwar eine 64bit Architektur haben, aber deren FPU oft 128bit Arithmetik unterstüzt. Ich konnte mir nicht vorstellen, wieso die FPU so präzise sein soll, wir aber immernoch `double` Variablen verwenden. Wenn man das aber zum parallelen Rechnen benutzt, dann ist das vollkommen verständlich
Danke für die Antwort.
-
FirefoxMetzger schrieb:
Die CPUs die mich interessieren sind die 'gängigen' desktop CPUs (also Intels i3, i5, i7 und AMD äquivalente).
Wikipedia schrieb:
Note: Not all CPUs from the listed families support AVX. Generally, CPUs with the commercial denomination "Core i3/i5/i7" support them, whereas "Pentium" and "Celeron" CPUs don't.
-
FirefoxMetzger schrieb:
Haben moderne CPUs eine eigene FPU?
Hallo Dornröschen!
Ja, aber klar.
Mittlerweile kann man sogar Dateinamen oder Variablen mit mehr als 8 Buchstaben einsetzen. Aber so ganz sicher bin ich mir nicht.
Sonderzeichen sind noch immer mit Vorsicht zu benutzen und können zu bösen Abstürzen führen.
Abstürze machen manchmal auch einfache Rechenfehler, die dann aber ganz bestimmt mit maximaler Genauigkeit.
-
nachtfeuer schrieb:
FirefoxMetzger schrieb:
Haben moderne CPUs eine eigene FPU?
Hallo Dornröschen!
Ja, aber klar.
Mittlerweile kann man sogar Dateinamen oder Variablen mit mehr als 8 Buchstaben einsetzen. Aber so ganz sicher bin ich mir nicht.
Sonderzeichen sind noch immer mit Vorsicht zu benutzen und können zu bösen Abstürzen führen.
Abstürze machen manchmal auch einfache Rechenfehler, die dann aber ganz bestimmt mit maximaler Genauigkeit.War die Frage nicht eher so gemeint, ob sie noch eine FPU (im Sinne von x87) haben? Ich bin mir da nicht 100% sicher, wie es in der Hardware momentan aussieht. x87-Befehle verstehen sie natürlich, aber deren 80-Bit Genauigkeit könnte intern theoretisch auch auf die neueren, 128 Bit breiten, Versionen von SSE/AVX & Co. abgebildet werden, ohne dass man das nach außen sieht. Bei der Art und Weise, wie Befehlsdecodierung in CPUs funktioniert, sollte das möglich sein. Andererseits sollte es auch kein große Aufwand sein, einen gammeligen 587er mit in die CPU einzubauen für alte Anwendungen. Wie das tatsächlich geregelt ist, kann ich trotz einigem Suchens nicht finden, da müsste ich tiefer nachforschen als ich Zeit habe.
-
SeppJ schrieb:
x87-Befehle verstehen sie natürlich, aber deren 80-Bit Genauigkeit könnte intern theoretisch auch auf die neueren, 128 Bit breiten, Versionen von SSE/AVX & Co. abgebildet werden, ohne dass man das nach außen sieht.
*hust*hust*
dachschaden schrieb:
(Nur, weil deine Register 256 Bits halten können, heißt das nicht, dass du 256-Bit-Gleitkommazahlen berechnen kannst. Diese Instruction Sets sind vor allem auf Parallelität ausgerichtet).
Wikipedia schrieb:
SSE used only a single data type for XMM registers:
- four 32-bit single-precision floating point numbers
SSE2 would later expand the usage of the XMM registers to include:
- two 64-bit double-precision floating point numbers or
- two 64-bit integers or
- four 32-bit integers or
- eight 16-bit short integers or
- sixteen 8-bit bytes or characters.Wikipedia schrieb:
AVX uses sixteen YMM registers. Each YMM register contains:
- eight 32-bit single-precision floating point numbers or
- four 64-bit double-precision floating point numbers.Ich behaupte einfach mal steil, dass ein 80-Bit-Register nicht in 64-Bit-Register passen. Für 64-Bit-Zahlen mag das noch passen, aber für
long doubles wird's schwierig. Das wissen (gute) Compiler aber auch. Für 64-Bit-GKZ werden SSE-Instruktionen und für 80-Bit-GKZ werden x87-Instruktionen generiert (gerade noch mal geprüft).Der erste SSE-Prozessor (Pentium III) konnte übrigens nicht gleichzeitig eine x87- und eine SSE-Anweisung verarbeiten, weil gemeinsame Ressourcen verwendet wurden. Danach arbeiteten diese getrennt.
-
dachschaden schrieb:
...
Das ist die logische Beschreibung des Befehlssatzes. Dass die nicht kompatibel sind, wird wohl niemand anzweifeln. Die Frage war doch, welche Hardware dahinter steht¹. Ist da wirklich noch ein separater Transistorcluster für eine x87-FPU? Wahrscheinlich ja, behaupte ich mal, aber es muss nicht unbedingt so sein.
¹: Alles was du beschreibst, könnte theoretisch als Fließkommaemulation laufen.
-
Vielleicht kann ich ja etwas sinvolles zur Diskussion beitragen, indem ich den Hintergrund meiner Frage ein bisschen genauer darstelle.
Mein Ausgangspunkt war die IEEE 754 - 2008 , welche der de facto Standard zur Darstellung von Gleitkommazahlen ist. Für binäre Zahlen existieren die Formate binary16, binary32, binary64, binary128 sowie binary{k} wobei k > 128 und ein vielfaches von 32 . Selbes Spiel für decimal32, decimal64, ... wobei diese Darstellung erst ab 32 bit existiert.
Dieser Standard ist (theoretisch) nach oben offen und macht Vorgaben für eine 1024bit floating point variable. Vor allem aber genaue Angaben zur binary128. Folglich habe ich mich gefragt ob die gängigen CPUs Hardwarebeschleunigung für eine so große Zahl bieten (also arithmetik + -, ... in einem Taktschritt berechnen können).
Hinzu kommt, dass ich in einem anderen Forum einen Kommentar gelesen habe, dass gängige CPUs 128bit oder 256bit Register für floating point Operationen haben, was ich als Inditz für die existens der entsprechenden Hardware gewertet habe.
Als ich dann allerdings danach gegooglet habe, habe ich keine Aussage über die Größe der FPU auf CPUs gefunden (in den entsprechenden Datenblättern). Daher die Frage ob CPUs überhaupt noch eine dedizierte FPU haben, oder das ganze doch irgendwie anders als erwartet funktioniert.
dachschaden hat meine Verwirrung dann zum Glück so weit auflösen können, dass ich jetzt verstehe warum die Register so groß sind, aber trotzdem 'nur' 64bit Hardwarebeschleunigung existiert.
In der Praxis sind es dann oft sowieso nur 'Eckfälle' die man entspannt den Compilern überlässt. Aber es ist trotzdem wichtig zu wissen, wo diese Grenzen sind. Wenn ich also in eine 128bit floating point implementierung renne, weiß ich dass ich von der nur deutlich geringere Leistung erwarten kann als von 32 oder 64bit.
-
SeppJ schrieb:
War die Frage nicht eher so gemeint, ob sie noch eine FPU (im Sinne von x87) haben? Ich bin mir da nicht 100% sicher, wie es in der Hardware momentan aussieht.
Muss es unbedingt 100% sein? Ich könnte so 50 anbieten..
Hier wäre eine Seite, die ich ganz gut finde:
http://dresdenboy.blogspot.de
Es geht natürlich noch etwas übersichtlicher:
http://www.anandtech.com/show/6355/intels-haswell-architecture/8Eine andere Frage wäre, welche Befehle gehen, welche Datenbreiten usw.? Beliebt: aktuellen gcc bemühen.
(gilt auch für arm und andere)MMX war ja zum großen Teil (und ist noch immer) Marketing Geblubber (wie auch bei amd) - keine Chance gegen die Rechenkraft der Grafikkarten - aber Intel hatte zu dieser Einführungszeit keine neue Technik bemüht.
(vermutlich ökonomische Überlegungen).
Und die Grafikkarten haben fast das gleiche Hardwareproblem (viel parallel) und begrenzen die Datenbreite daher.
FPU und MMX/SSE sind genaugenommen zwei unterschiedliche Schubladen - In einen Top werfen muss man die nicht.Was ham wa noch?
Softwaresimulationen.
1. Nicht mehr so langsam wie früher ->z.B. softwaresynths im System*
2. Eigene Datenformate, hardwaretechnisch optimiert (ist fast das gleiche).*Highend-Sampler liefen früher mit 16 Bit. Mehr braucht man gar nicht, vielleicht 20 für bessere Rauschwerte.
Mit den neuen Vectoreinheiten ersetzt man zwar keinen DSP - macht trotzdem irgendwie Spaß so zu tun als ob.
-
@FirefoxMetzger:
Wenn du es so schön klar formulierst, gibt es eine eindeutige Antworten auf deine Fragen:-Dedizierte FPU Hardware? Ja!
-128 Bit? Ja, aber nur bei ziemlich neuen CPUs mit AVX2 oder besser¹. Und natürlich muss das Programm mit speziell den Instruktionen dafür erstellt worden sein, setzt also einen Compiler voraus, der diesen Befehlssatz kennt und Code für diesen CPU-Typ erzeugt.
Vielleicht noch zwei weitere Bemerkungen:
-GPUs können meistens nur 32 Bit floats, außer es sind spezielle GPUs für wissenschaftliches Rechnen.
-Es ist relativ zweifelhaft, dass man jemals 128 Bit Genauigkeit brauchen wird für eine Rechnung, die sich auf die reale Welt bezieht. double ist schon sehr viel genauer als jede in der Welt erreichbare Präzision². Höhere Rechengenauigkeit ist daher vor allem etwas für theoretische Werke oder für irgendwelche tollen Hacks.¹: Außerdem können das auch jede Menge nicht-Desktop CPUs, auch schon in den 1970ern. Aber ich nehme mal an, dass du vor allem an der x86-Familie interessiert bist.
²: Daher auch die Einschränkung vieler GPUs auf 32 Bit. Das ist einfach bei weitem präzise genug für alles, was man auf einem Monitor darstellen könnte.
-
Nur ergänzend: ein hierzu (wieder mal) recht lesenswerter Artikel von Andreas Stiller (Ct-Heft, Rubrik "Prozessorgeflüster", diese Artikel sind wie das Editorial im Internet verfügbar):
http://www.heise.de/ct/ausgabe/2016-19-Von-Medien-und-Meditationen-3307997.html
(u.a. wird der Trend zu 16 Bit Fließkommabeschränkung (oder Int) für Deep Learning angesprochen - schneller Daten schaufeln, s.o.)
