Itanium2: Rundung / double extended

HeinzSchmolke · 13.04.2005

Hallo,

hab ein bisschen das Gefühl, dass ich hier nicht ganz am richtigen Platz für meine Frage bin, aber ich probiere es trotzdem mal ...

Ich bin auf der Suche nach Informationen zum Itanium2-Prozessor. Und zwar möchte ich gerne wissen, wie man in den einzelnen Pipelines die Rechengenauigkeit beim Runden einstellen kann (up, down, nearest). Geht das nur auf Assembler-Ebene oder gibt es auch Möglichkeiten, aus einer Sprache wie C/C++ das ganze anzusteuern? Interessant ist das für die Intervallarithmetik, wenn die gleiche Rechnung in zwei Pipelines durchgeführt werden soll, die beide eine unterschiedliche Rundung verwenden.

Desweiteren brauche ich Informationen, wie effektiv Zahlenformate wie long double (double extended, 80bit) auf Hardware-Ebene unterstützt werden (schliesslich ist der Prozessor auf 64bit-Formate 'optimiert', also beste Unterstützung für 'normales' double (double precision).

Würde mich freuen, falls mir jemand weiterhelfen kann. Sei es durch nen Verweis auf das richtige Forum, ein vernünftiges Buch oder nen Kontakt zu jemanden, der sich damit bestens auskennt.

Besten Dank
Heinz

mtb][sledgehammer · 13.04.2005

Erstmal willkommen im P3D Forum.

Ansonsten denke ich hast du das Thema schon recht gut plaziert, einzige andere Möglichkeit wäre vielleicht noch im Programmierforum, aber hier ist eben auch der Übergang fließend

Leiderkann ich dir bei deinem Problem nicht wirklich weiterhelfen, da wäre wohl alles geraten, eventuell findest du aber bei Intel direkt ein paar gute Dokumente (ähnliches habe ich zumindest schon für den Pentium 4 gefunden, oder bei AMD für den Athlon 64/Opteron).

Ansonsten gibt es unter folgenden Adressen meist recht informative Artikel:
http://arstechnica.com/index.ars
http://www.realworldtech.com/
http://www.digit-life.com/

i_hasser · 13.04.2005

Mich dünkt, dass es bei der x86 FPU nicht einzustellen geht. Schätze mal, dass das bei anderen Architekturen nicht anders sein wird, normalerweise reicht es ja aus wenn die Ergebnisse irgendeiner Genauigkeitspezifikation entsprechen (wieder das I mit den 3 Es).

Definitiv beeinflussen kann man es bei der Umwandlung von Float zu Integer, auch in C (floor, ceil etc.).

Die Rundung bei FPU Operationen betrifft ja aber praktisch alles was die FPU so kann, von daher dürfte das fest verdrahtet sein, weil wie gesagt einfach das Einhalten einer gewissen Spezifikation ausreicht.

RLZ · 13.04.2005

Erste Anlaufstelle bei solchen Problemen ist immer der Hersteller

Zu jedem Prozessor gibts eigentlich auch immer Programming Guides etc.
Vielleicht kannst du ja hier was zu deinen Problemen finden.

Dresdenboy · 13.04.2005

i_hasser schrieb:
Mich dünkt, dass es bei der x86 FPU nicht einzustellen geht. Schätze mal, dass das bei anderen Architekturen nicht anders sein wird, normalerweise reicht es ja aus wenn die Ergebnisse irgendeiner Genauigkeitspezifikation entsprechen (wieder das I mit den 3 Es).

Es geht einzustellen - und ich glaube sogar, daß das möglich sein muß, will die FPU dem IEEE 754 Standard entsprechen. Auch andere Sachen, wie z.B. die Aktion bei Ausnahmefällen sind einstellbar (da kommt dann statt NAN halt 0.0 zurück). Das nutzt z.B. Prime95 aus.

@Thread:
Auf der von mtb][sledgehammer verlinkten Realworldtech-Seite gibt es auch ein Forum, wo man auch mal (ohne Anmeldung) diese Frage posten kann. Dort sind einige Leute aktiv, die u.a. starke Verfechter des Itanium (Paul DeMone) oder auch andere, die sehr tiefgründiges Wissen besitzen.

Evtl. hilft auch die comp.arch-Newsgroup, auf der man auch mit Google posten kann.

Aber ich denke mal, es geht zwar einzustellen, aber nicht für Pipelines getrennt. Evtl. hilft folgendes PDF weiter:
http://www4.ncsu.edu/~efg/wcae/2003/submissions/cornea.pdf

HenryWince · 13.04.2005

@HeinzSchmolke

Und zwar möchte ich gerne wissen, wie man in den einzelnen Pipelines die Rechengenauigkeit beim Runden einstellen kann (up, down, nearest).

Der Itanium hat nur eine inorder Pipeline hat aber mehrere Issue Ports. Die aktuelle Itanium2 Generation besitzts 2 FP Issue Ports und auch zwei FPUs, d.h. es 2 FP Instructions paralell ausgeführt werden. Die CPU verhält sich folgendermaßen:

Das Floating Point Status Register (FPSR = Application Register 40 = AR40) enthält einen Bereich mit dem man Festlegt welche FP Traps einschalten sind. Desweiteren enthält das FPSR vier gleich aufgebaute Status Felder die extra Status Bits und den Rundungsmodus enthalten.

Die einzelnen FP Anweisungen enthalten Zusatzinformationen welches dieser Felder genutzt werden soll. D.h. man könnte damit "on the fly" aus 4 Rundungsmodi selektieren.

Auf einem etwas anderen Blatt steht ob das OS den vollen Zugriff auf das FPSR gewährt.

Geht das nur auf Assembler-Ebene oder gibt es auch Möglichkeiten, aus einer Sprache wie C/C++ das ganze anzusteuern?

Es geht auch auch C/C++ Ebene wenn der Compiler und das Betriebssystem mitspielen. Am besten nimmt man einen Compiler welcher der C99 Spec. entspricht.

Desweiteren brauche ich Informationen, wie effektiv Zahlenformate wie long double (double extended, 80bit) auf Hardware-Ebene unterstützt werden (schliesslich ist der Prozessor auf 64bit-Formate 'optimiert', also beste Unterstützung für 'normales' double (double precision).

Bei IA64 wird erst mal alles in das interne 82-Bit Registerformat gewandelt, dann wird damit gerechnet. D.h. für die reine Berechungszeit gibt es keinen Unterschied zwischen Float, Double oder Extended.

Mit "Long Double" must du aufpassen, weil das von manchen Compilern als "quad" aka "Real * 16" (128Bit Format mit 1 Bit Sign/15Bit Exponent/1Bit Implzit/112 Bit Mantisse explizit) interpretieren und dann mit Software-Emulation arbeiten.

HeinzSchmolke · 13.04.2005

i_hasser schrieb:
Mich dünkt, dass es bei der x86 FPU nicht einzustellen geht. Schätze mal, dass das bei anderen Architekturen nicht anders sein wird, normalerweise reicht es ja aus wenn die Ergebnisse irgendeiner Genauigkeitspezifikation entsprechen (wieder das I mit den 3 Es).
[...]
Die Rundung bei FPU Operationen betrifft ja aber praktisch alles was die FPU so kann, von daher dürfte das fest verdrahtet sein, weil wie gesagt einfach das Einhalten einer gewissen Spezifikation ausreicht.

Doch, man muss es einschalten können. Irgendeine Rechengenauigkeit reicht mir eben nicht aus. Einfaches Beispiel sind Skalarprodukte, bei denen schon bei wenigen Operationen und nur einem minimalen Ausnutzen des Darstellungsbereiches eklatante Fehler auftreten können. Dem Benutzer wird vorgegaukelt (am besten durch unheimlich viele Nachkommastellen), dass das berechnete Ergebnis 'exakt' ist, jedoch kann das wahre Ergebnis ein komplett anderes Vorzeichen haben und von gänzlich anderer Grössenordnung sein. Ausserdem sollte das Ergebnis identisch sein, egal in welcher Reihenfolge die Summanden addiert werden. Das ist bei jeder Art von gerundeten Datenformaten der Fall und wenig zufriedenstellend.
Intervallarithmetik _garantiert_ jedoch, dass das Ergebnis einer Rechnung innerhalb eines Intervalls mit 100% Sicherheit liegt. Dazu sind jedoch bei jeder Operation verschiedene Rundungen nötig. Das Umschalten der Rundung ist jedoch (zumindest bei x86) mit hohen Kosten verbunden.

HenryWince schrieb:
@HeinzSchmolke
Der Itanium hat nur eine inorder Pipeline hat aber mehrere Issue Ports. Die aktuelle Itanium2 Generation besitzts 2 FP Issue Ports und auch zwei FPUs, d.h. es 2 FP Instructions paralell ausgeführt werden. Die CPU verhält sich folgendermaßen:

Das Floating Point Status Register (FPSR = Application Register 40 = AR40) enthält einen Bereich mit dem man Festlegt welche FP Traps einschalten sind. Desweiteren enthält das FPSR vier gleich aufgebaute Status Felder die extra Status Bits und den Rundungsmodus enthalten.

Die einzelnen FP Anweisungen enthalten Zusatzinformationen welches dieser Felder genutzt werden soll. D.h. man könnte damit "on the fly" aus 4 Rundungsmodi selektieren.

Bin leider bislang (noch) nicht allzusehr mit Prozessoren vertraut (bin Mathematiker), daher die Frage: welche Aufgabe übernehmen die inorder Pipeline und die Issue Ports? Kannst du da gute Literatur empfehlen, die über solche (grundlegenden) Dinge informiert und am besten in jeder gut sortierten Uni-Bibliothek zu finden ist?

HenryWince schrieb:
Auf einem etwas anderen Blatt steht ob das OS den vollen Zugriff auf das FPSR gewährt.

Es geht auch auch C/C++ Ebene wenn der Compiler und das Betriebssystem mitspielen. Am besten nimmt man einen Compiler welcher der C99 Spec. entspricht.

Auch hier wieder die Frage: wo finde ich den entsprechenden Passus innerhalb der C99 Spezifikationen und welche Compiler die Spezifikation in diesem Part genau unterstützen.

HenryWince schrieb:
Bei IA64 wird erst mal alles in das interne 82-Bit Registerformat gewandelt, dann wird damit gerechnet. D.h. für die reine Berechungszeit gibt es keinen Unterschied zwischen Float, Double oder Extended.

Mit "Long Double" must du aufpassen, weil das von manchen Compilern als "quad" aka "Real * 16" (128Bit Format mit 1 Bit Sign/15Bit Exponent/1Bit Implzit/112 Bit Mantisse explizit) interpretieren und dann mit Software-Emulation arbeiten.

Danke für die Info bezüglich 'quad'. Wird interessant, mit welchem Performanceverlust Rechnungen mit quad gegenüber double verbunden sind.
Meine Intuition hätte jetzt gesagt, dass bei IA64 vieles/alles auf 64bit optimiert wird, folglich auch 64bit-Formate wie double am besten von der Hardware unterstützt werden. Wie muss ich mir das vorstellen: ich definiere eine Operation von float-Zahlen, die auf 82bit 'künstlich aufgebläht' werden und anschliessend wieder auf float-Grösse 'abgeschnitten' werden? Da ist bestimmt gerade ein eklatanter Denkfehler dabei, oder?

Besten Dank soweit für die ausführliche Hilfe.
Heinz

i_hasser · 13.04.2005

Puh, versuche das mal Mathematikergerecht auszudrücken

:

Es gibt irgend eine IEEE(große Zahl)-Spezifikation, die vorschreibt in welchem Rahmen die Abweichungen bei Float-Berechnungen liegen dürfen. Praktisch jede FPU hält sich daran, weil das für wissenschaftliche Berechnungen sonst ein ziemlicher Nachteil wäre. Normal ist afair eine garantierte Genauigkeit von 80Bit Float, sprich innerhalb dieser 80Bit Genauigkeit entspricht das errechnete Ergebnis dem tatsächlichen Ergebnis.

Das bezieht sich aber in jedem Fall nur auf einzelne Operationen, weil sich die Ungenauigkeiten logischerweise addieren können. In der Realität sprich im Informatiker-Alltag kann man damit aber leben

. Braucht man wirklich extreme Genauigkeiten greift man sowieso nicht auf die FPU zurück, sondern auf Algebra-Systeme. Die FPU ist zwar verglichen damit sauschnell, von der Genauigkeit her aber limitiert - reicht für 99% der Fälle aber so.

Bin leider bislang (noch) nicht allzusehr mit Prozessoren vertraut (bin Mathematiker), daher die Frage: welche Aufgabe übernehmen die inorder Pipeline und die Issue Ports? Kannst du da gute Literatur empfehlen, die über solche (grundlegenden) Dinge informiert und am besten in jeder gut sortierten Uni-Bibliothek zu finden ist?

Ein Issue-Port ist grob gesagt der Eingabeport für die zu berechnenden Sachen (naja... ist etwas arg grob ausgedrückt).

Wenn dir Pipelining ein Begriff ist: Der Itanicum hat nur eine recht einfach gehaltene Pipeline, die allerdings mehrere Sachen in einem Rutsch berechnen kann. Jeder Issue-Port steht dabei für eine der parallelen Berechnungen.

Bei der Itanium Architektur bin ich aber auch alles andere als fit.

HeinzSchmolke · 14.04.2005

i_hasser schrieb:
Puh, versuche das mal Mathematikergerecht auszudrücken :

Das bezieht sich aber in jedem Fall nur auf einzelne Operationen, weil sich die Ungenauigkeiten logischerweise addieren können. In der Realität sprich im Informatiker-Alltag kann man damit aber leben . Braucht man wirklich extreme Genauigkeiten greift man sowieso nicht auf die FPU zurück, sondern auf Algebra-Systeme. Die FPU ist zwar verglichen damit sauschnell, von der Genauigkeit her aber limitiert - reicht für 99% der Fälle aber so.

Jein. Wünschenswert wäre es aus meiner Sicht, wenn Prozessoren neben den vier Grundrechenarten +,-,*,/ ausserdem das Skalarprodukt unterstützen würden, also eine Abfolge von Multplikationen und Additionen, die mit maximal einer einzigen Rundung am Ende auskommt. Es ist in heutigen Zeiten aus meiner Sicht einfach unzureichend, dass ein Ergebnis _nur_ mit hoher Wahrscheinlichkeit richtig ist. Eine normale Addition à la 10^30 + 1 - 10^30 ergibt in double precision schon den Wert 0. Eine einfache Aufgabe, die jeder Grundschüler korrekt im Kopf lösen kann, ein leistungsfähiger Rechner scheitert jedoch daran.
Emulation auf Softwareebene ist ja nur eine Not-Lösung, die mit unverhältnismässig hohem Rechenaufwand einhergeht. Scheinbar gibt es für diesen Standpunkt seit über 40 Jahren keine Lobby. Aber nun gut, dass soll auch nicht Thema der Diskussion sein.

Wenn dir Pipelining ein Begriff ist: Der Itanicum hat nur eine recht einfach gehaltene Pipeline, die allerdings mehrere Sachen in einem Rutsch berechnen kann. Jeder Issue-Port steht dabei für eine der parallelen Berechnungen.

Ok, hab es wohl in den Grundzügen verstanden. Ich ging davon aus, dass der Itanium2 gleich mehrere Pipelines besitzt. Sehe gerade, dass HenryWince auch schon drauf hingewiesen hat, dass der Itanium2 nur eine einzige Pipeline besitzt. Habe die eigentlich wichtige Aussage in dem Satz schlichtweg überlesen.

HenryWince · 14.04.2005

@HeinzSchmolke

Bin leider bislang (noch) nicht allzusehr mit Prozessoren vertraut (bin Mathematiker), daher die Frage: welche Aufgabe übernehmen die inorder Pipeline und die Issue Ports? Kannst du da gute Literatur empfehlen, die über solche (grundlegenden) Dinge informiert und am besten in jeder gut sortierten Uni-Bibliothek zu finden ist?

Der absolute Klassiker ist "Computer Architecture" von Hennessey & Patterson. Schau dir auch mal "Computer Organization and Design. The Hardware/Software Interface" von David Patterson an. Vom Inhalt könnte das fast intersanter für dich sein, aber die Strukturierung des Textes ist an manchen Stellen arg gewöhnungsbedürftig.

Eine Pipeline kannst du dir wie ein Fließband vorstellen. Die zwei FP Issue Ports wären dann analog dazu zwei Arbeiter die je links und rechts vom Band stehen und jeweils ein Werkstück z.B. in eine Stanzmaschiene (FPU) halten. Was die Stanzmaschienen machen ist unabhängig (es können zum gleichen Zeitpunkt zwei Werkstücke bearbeitet werden), aber der gesamte Prozess ist dennoch synchronisiert und verläuft seriell.

Auch hier wieder die Frage: wo finde ich den entsprechenden Passus innerhalb der C99 Spezifikationen und welche Compiler die Spezifikation in diesem Part genau unterstützen.

C99 ist ANSI/ISO/IEC 9899:1999, Programming languages C.

Den letzten öffentlichen Draft kann man kostenfrei hier runter laden. Siehe Kapitel 7.6

Die meisten Compiler sollten inzwischen C99 unterstützen. MW. ist zumindest der HP-UX Compiler. GCC hat noch Probleme.

Desweitern gibt es feine Unterschiede zwischen den C99 und C98++ (ANSI/ISO/IEC 14882:1998, Programming languages C++) Floating Point Bindings (siehe da).

Wie muss ich mir das vorstellen: ich definiere eine Operation von float-Zahlen, die auf 82bit 'künstlich aufgebläht' werden und anschliessend wieder auf float-Grösse 'abgeschnitten' werden? Da ist bestimmt gerade ein eklatanter Denkfehler dabei, oder?

So ungefähr. Der Trick ist, das wenn FP Werte aus dem Speicher geladen diese in die interne Registerdarstellung mit 82 Bit konvertiert werden. Wenn man den max. Wertebereich nutzen will kann der Compiler jetzt einfach nur FP Anweisungen für extended precision erzeugen (M.W. ist das default bei den meisten Compilern). Es ist aber auch möglich explizit mit der gewählten Genauigkeit zu rechnen. Dafür gibts dann entsprechende Compiler Switches. Die Hardware verarbeitet immer 82 Bit, liefert aber je nach Datenformat natürlich unterschiedliche Overflow/Underflow Conditions. Ich wollte eigentlich nur darauf hinaus, dass es für die Rechen-Performance keine Rolle spielt ob man mit Float, Double oder Extended rechnet. Für die Gesamtperformance spielt das verwendete Float-Format in so fern eine Rolle, als man natürlich die Load/Storebandbreite berücksichtigen muss.

Wünschenswert wäre es aus meiner Sicht, wenn Prozessoren neben den vier Grundrechenarten +,-,*,/ ausserdem das Skalarprodukt unterstützen würden, also eine Abfolge von Multplikationen und Additionen, die mit maximal einer einzigen Rundung am Ende auskommt.

Der Itanium kennt nur eine Multiply-Add Anweisung (rx = ra*rb +rc). Addition wird von Compiler auf ist rx = FP1*rb+rc abgebildet, Multiplikation auf rx = ra * rb + FP0. FP0 enthält immer 0.0, FP1 immer 1.0. Division/Wurzel/Trig. wird per SW erledigt, zur Beschleunigung gib es noch zwei Approximations-Anweisungen -- eine für Rezipokwerte, eine für SQRT.

i_hasser · 14.04.2005

Das mit der Genauigkeit ist eben so eine Sache, in 90% der Fälle braucht man nichtmal 64Bit Floats. Außerdem wäre es von der Implementierung her deutlich aufwändiger, wenn man so viel Wert auf Genauigkeit legen würde. Die x86 FPU rechnet übrigens auch nur mit 80Bit.

Und zu guter letzt ist es bei praktisch allen RISC-ähnlichen Befehlssätzen schwierig komplexe Befehle zu finden - das Skalarprodukt 2er Vektoren wäre ja schon eine ziemlich komplexe Operation.

Mit SSE ließe sich da aber auch was machen. Allerdings nur mit max. 64Bit Genauigkeit.

Es ist wie gesagt einfach ein praktisches Problem, weil im Regelfall schon 32Bit Genauigkeit ausreichen.

HeinzSchmolke · 14.04.2005

HenryWince schrieb:
@HeinzSchmolke
Der absolute Klassiker ist "Computer Architecture" von Hennessey & Patterson. Schau dir auch mal "Computer Organization and Design. The Hardware/Software Interface" von David Patterson an. Vom Inhalt könnte das fast intersanter für dich sein, aber die Strukturierung des Textes ist an manchen Stellen arg gewöhnungsbedürftig.

C99 ist ANSI/ISO/IEC 9899:1999, Programming languages C.

Den letzten öffentlichen Draft kann man kostenfrei hier runter laden. Siehe Kapitel 7.6

Die meisten Compiler sollten inzwischen C99 unterstützen. MW. ist zumindest der HP-UX Compiler. GCC hat noch Probleme.

Desweitern gibt es feine Unterschiede zwischen den C99 und C98++ (ANSI/ISO/IEC 14882:1998, Programming languages C++) Floating Point Bindings (siehe da).

super. Werde die Sachen mal durchackern. Habe mir auch noch zwei Bücher von Triebel und von Cornea 'Scientific Computing on Itanium®-based Systems' bestellt und werde mich fleissig weiterbilden.

i_hasser schrieb:
Das mit der Genauigkeit ist eben so eine Sache, in 90% der Fälle braucht man nichtmal 64Bit Floats. Außerdem wäre es von der Implementierung her deutlich aufwändiger, wenn man so viel Wert auf Genauigkeit legen würde. Die x86 FPU rechnet übrigens auch nur mit 80Bit.

Und zu guter letzt ist es bei praktisch allen RISC-ähnlichen Befehlssätzen schwierig komplexe Befehle zu finden - das Skalarprodukt 2er Vektoren wäre ja schon eine ziemlich komplexe Operation.

Es ist wie gesagt einfach ein praktisches Problem, weil im Regelfall schon 32Bit Genauigkeit ausreichen.

Ok, da werden wir wohl nicht auf eine ähnliche Meinung kommen. Was bringt es mir, wenn der Computer zu 90% immer richtig rechnet, ich aber nicht weiss, wann das Ergebnis mal verkehrt ist .... Du kannst praktisch nie voraussagen, welche Zwischenergebnisse in einem Algorithmus auftreten und welche Probleme das bei der weiteren Berechnung ergeben kann. Für mich ein unzureichender Zustand in Zeiten, wo es ohne weiteres möglich ist, 'exakte' Gleitkommarechnung auf Hardware nachzubilden und die man bei Bedarf benutzen kann.

Dresdenboy · 14.04.2005

HeinzSchmolke:
Hast du dir das von mir verlinkte Paper schon angesehen? Das dürfte schon viele Fragen beantworten. Ein weiteres könnte dir beim Verständnis der Architektur ebenfalls behilflich sein: http://www.diku.dk/undervisning/2005f/303/Itanium.pdf

Wie ich mittlerweile gelesen habe, erlaubt es der Itanium, daß jede FPU-Instruktion separat den Rundungsmodus auswählen kann. Es ist dann eigentlich egal, in welche FP-Einheit dieser Befehl geht, weil der Rundungsmodus sich von Befehl zu Befehl ändern kann. Wie das Ganze in C/C++ realisiert werden kann, weiß ich allerdings nicht. Und das OS hindert einen sicher kaum an der Nutzung verschiedener Rundungsmodi. Das ist schließlich Sache der Applikation.

Die Genauigkeit bezüglich 80 bit sollte dem von x87 her gewohnten Standard entsprechen (zu dem der Itanium ja auch kompatibel sein will). Intern wird mit 82 bit gerechnet. Das der Itanium 2 eine 64-bit-Architektur ist, wirkt sich hier nicht aus. Selbst die ersten mathematischen Koprozessoren für die 16-bit-x86-CPUs konnten mit 80 bit umgehen. Beim Itanium beziehen sich die 64-bit auf die Verarbeitungsbreite bei Integer-Werten und auch auf den theoretisch möglichen virtuellen Adressraum (welcher meist auf weniger Bit reduziert ist, wie auch der physikalische Adressraum).

Die höchste interne Genauigkeit, die mir z.Z. bekannt ist, hat der K8 von AMD in Form des Opterons oder Athlon 64. Möglicherweise arbeitet die Athlon-CPU (K7) auch schon so genau. Und zwar sind es dort 87 bit (68 bit Mantisse, 18 bit Exponent, 1 Sign bit, siehe hier) intern (auch bei SSE2-Berechnungen wirksam, sofern die Werte in den Registern gehalten werden).

Und Personen, die schon einige Erfahrung auf dem Itanium 2 haben, findest du im schon erwähnten Realworldtech-Forum (dort gibt es auch mehrere tiefgründige Artikel zu IA-64), aber auch das Mersenne-Forum. Dort trifft man neben George Woltman (Prime95-Entwickler) auch E. W. Mayer (Entwickler von mlucas - welches in einer frühen Version in den SPEC-CPU-Benchmarks enthalten ist) und Guillermo Ballester Valor (hat sein Glucas-Programm auf den Itanium portiert, um für den Lucas-Lehmer-Test mehrere CPUs parallel zu nutzen - zumindest für die Berechnung der FFTs). Und bei größeren FFTs stellt sich ja auch recht schnell die Frage nach Genauigkeit.

i_hasser:
Es geht hier offensichtlich um wissenschaftliche Berechnungen. Da ist man durchaus schonmal an der höchstmöglichen Genauigkeit interessiert

i_hasser · 14.04.2005

Na in der Praxis summieren sich die Ungenauigkeiten einfach nicht so hoch, als das es einen Unterschied machen würde. Ist doch egal, ob in irgend einem Spiel der eine Vertex 1e-12 weiter weg vom Beobachter sitzt oder nicht, die GPUs rechnen sowieso mit viel größeren Ungenauigkeiten und selbst das macht sich auf dem Bildschirm schon nicht bemerkbar.

Es gab mal ein Problem mit Runung bei der FPU, und zwar beim Pentium Bug. Der Bug bestand darin, dass die Abweichungen bei einigen Berechnungen verhältnismäßig groß wurden (afair Größenordnungen von 1e-12), und da haben sich die Fehler dann soweit potenziert, als dass es Ergebnisse beeinflusst hat.

Nur ist es eben auch eine Implementierungsfrage. Wenn man zB. MPEG Codierung durchführt sind die kleinen Ungenauigkeiten eh unteressant, und wenn man irgend ein Spiel hernimmt, dann stellen die Spielfigurpositionen auch keine Herausforderung für einen 32Bit Float dar, geschweige denn für einen 64Bit Float.

Bei Integern bestimmt man mit der Breite den abgedeckten Bereich, bei Floats die Genauigkeit. Wenn du eben 1+1e-30 als Float speichern willst, dann müsste der mindestens 103 Bit breit sein. Wenn du 1+1e-60 speichern willst, dann wären schon mindestens 206 Bit nötig.

Für bestimmte Bereiche taugen die 80Bit Floats nichts, aber das greifbarste, was mir da einfällt, sind Fraktalgeneratoren. Da muss man wohl oder übel auf Softwarebasierte Sachen zurückgreifen, oder man macht hälfte/hälfte (was bei Float allerdings nicht mehr so einfach ist).

Naja, ich denk das ist irgendwo auch eine Gewöhnungsfrage. Ich hab mich dran gewöhnt, dass eine FPU eben nicht exakt rechnet (wesswegen man Vergleiche bei Floats zB. auch nie mit == durchführen sollte, x+1-1 könnte !=0 sein, eben irgendwas wie zB. 1e-16).
Als Mathematiker arbeitest du mit den Sachen sicherlich auch anders, wo so eine Genauigkeit sicher auch erforderlich ist.

HenryWince · 14.04.2005

> Na in der Praxis summieren sich die Ungenauigkeiten einfach nicht so hoch, als das es einen Unterschied machen würde.

In der Praxis wissen die meisten gar nicht wie hoch die Fehler sein können! Bei einem Spiel ist es vollkomen egal. Wenn man aber wissenschaftliche oder auch "nur" Engineering Fragen beantworten will kommt man um eine Fehlerrechning nicht herum. Würdest du dich in ein Flugzeug setzten, bei dem die Designer einfach FEM Programm angeworfen haben OHNE genau zu wissen ob sie dem Ergebnis trauen können

Kleine Anekdote am Rande: Ich hab vor zig Jahren mal an einem Programierwettbewerb (68k Assembler) teilgenommen, bei dem es darum ging Pi möglichst genau zu berechnen.
Gewonnen hat ein Progktramm, mit dem man "beliebig viele" Stellen berechnen konnte. . Mein Programm wurde überhaupt nicht gewertet, weil ich nur um die 80'000 Stellen genau rechnen konnte (hab ich Anhand von Refernzdaten auch verifiziert). Der Witz an der Sache war, dass das Siegerprogramm eine Reihenentwicklung verwendet hat bei der die Genauigkeit der Integer-Division die tatsächlich erreichbare Genauigkeit auf 60'000 Stellen beschränkte.. Tja weder der Programierer noch die Jury machten sich dazu überhaupt Gedanken....

HeinzSchmolke · 14.04.2005

Dresdenboy schrieb:
Hast du dir das von mir verlinkte Paper schon angesehen? Das dürfte schon viele Fragen beantworten. Ein weiteres könnte dir beim Verständnis der Architektur ebenfalls behilflich sein: http://www.diku.dk/undervisning/2005f/303/Itanium.pdf

ja, habe soeben beide zuende gelesen. Da werden in der Tat alle meine wichtigsten Fragen aufgefriffen und erklärt. Besten Dank für beiden Links, hat mir enorm weitergeholfen.

Und Personen, die schon einige Erfahrung auf dem Itanium 2 haben, findest du im schon erwähnten Realworldtech-Forum (dort gibt es auch mehrere tiefgründige Artikel zu IA-64), aber auch das Mersenne-Forum. Dort trifft man neben George Woltman (Prime95-Entwickler) auch E. W. Mayer (Entwickler von mlucas - welches in einer frühen Version in den SPEC-CPU-Benchmarks enthalten ist) und Guillermo Ballester Valor (hat sein Glucas-Programm auf den Itanium portiert, um für den Lucas-Lehmer-Test mehrere CPUs parallel zu nutzen - zumindest für die Berechnung der FFTs). Und bei größeren FFTs stellt sich ja auch recht schnell die Frage nach Genauigkeit.

Da werde ich mich hinbegeben, sobald ich mich weiter mit den Papers und meiner frisch entliehenen Literatur auseinandergesetzt habe

Dresdenboy · 14.04.2005

i_hasser:
Versuche mal das hier zu berechnen und sorge dafür, daß der Compiler da nicht selbst herumoptimiert (also gleich das Ergebnis einträgt), z.B. durch die hier verwendeten Ausgaben zwischendurch oder Abschaltung aller Optimierungen:

Code:

double val1=1.0e8;
double val2=1.0e-8;
double val3=val1;
printf("%g",val3);
val3+=val2;
printf("%g",val3);
val3-=val1;
printf("%.12g",val3);

Es sollte 1.0e-8 übrig bleiben. Aber ich erhalten (VCC): 1.49011611938e-8 - nicht ganz das, was man erwartet

Jetzt stell dir statt dieser simplen Rechnungen nur mal etwas komplexeres vor.

In der Funktion als Game/Demo-Programmierer kann ich deine Einwände nachvollziehen, als Wissenschaftler aber nicht

i_hasser · 14.04.2005

Wollte in keinem Fall andeuten, dass es bei wissenschaftlichen Sachen nicht nötig ist genau zu wissen wie genau die Ergebnisse sind.

Nur machen AMD und Intel ihr Geld eben vorwiegend über Serveranwendungen (Integer), Multimedia-Geschichten (Float) und Office(int), wo die Genauigkeit so ziemlich keine Rolle spielt (64Bit reichen aus, oft auch 32Bit).
Und die FPU ist eben für diese Aufgaben desingt, wesswegen es auch diverse Abweichungen gibt, die im üblichen Einsatzzweck völlig im Rahmen bleiben.

Wollte eigentlich nur verdeutlichen, dass die FPU Genauigkeit für den Zweck für den die FPU vorwiegend zum Einsatz kommt, eben völlig ausreicht. Desswegen wird sich da wohl auch nicht viel dran ändern.

PuckPoltergeist · 14.04.2005

i_hasser schrieb:
Nur machen AMD und Intel ihr Geld eben vorwiegend über Serveranwendungen (Integer), Multimedia-Geschichten (Float) und Office(int), wo die Genauigkeit so ziemlich keine Rolle spielt (64Bit reichen aus, oft auch 32Bit).

Also das ist doch etwas arg blauäugig. Die meisten Itaniums gehen in Server, welche zu wissenschaftlichen Berechnungen genutzt werden. Das gleiche gilt für Opterons, welche in große Maschinen a la Supercomputer verbaut werden.
Mag ja sein, dass Intel und AMD mit dem Massenmarkt hauptsächlich ihre Brötchen verdienen. Deswegen kann man die Genauigkeit der Berechnungen trotzdem nicht per se als nebensächlich abtun.

i_hasser · 14.04.2005

Desswegen wird man aber eine FPU nicht von Grund auf neuentwickeln - sowas braucht nämlich Zeit.

Und wie du nunmal siehst, rechnen Itanium und Opteron mit 80Bit (effektiver Genauigkeit) - obwohl davon auch einige (bzw. beim Itanicum viele) für wissenschaftliche Aufgaben eingesetzt werden. Denn auch da gibt es Bereiche wo man sich zwar um die Abweichungen einen Kopf machen muss, mit 80Bit aber leben kann.

Das Problem ist nicht wie gerundet wird, sondern bei zB. 1+1e-20 einfach die größe des Float-Wertes. Und bevor man 128Bit FPUs mit allem drum und dran einführt, kann man das auch emulieren - solange nur ein Bruchteil diese Genauigkeiten wirklich dringend benötigt.

Dresdenboy · 15.04.2005

i_hasser schrieb:
Desswegen wird man aber eine FPU nicht von Grund auf neuentwickeln - sowas braucht nämlich Zeit.

Und wie du nunmal siehst, rechnen Itanium und Opteron mit 80Bit (effektiver Genauigkeit) - obwohl davon auch einige (bzw. beim Itanicum viele) für wissenschaftliche Aufgaben eingesetzt werden. Denn auch da gibt es Bereiche wo man sich zwar um die Abweichungen einen Kopf machen muss, mit 80Bit aber leben kann.

Das Problem ist nicht wie gerundet wird, sondern bei zB. 1+1e-20 einfach die größe des Float-Wertes. Und bevor man 128Bit FPUs mit allem drum und dran einführt, kann man das auch emulieren - solange nur ein Bruchteil diese Genauigkeiten wirklich dringend benötigt.

Ich habe hier ein schönes Dossier des Spektrums der Wissenschaft - Thema: Rechnerarchitektur. Da wurde auch dieses Genauigkeitsproblem angesprochen. Es gibt ja auch Berechnungen, wo die Zahlen um mehrere zig Zehnerpotenzen auseinanderliegen. Das erfordert dann noch ganz andere Verfahren. Die FPUs müssen dann auch nicht verändert werden. Aber es ist natürlich von Vorteil (auch für die Rechenleistung), wenn die FPUs eine hohe Genauigkeit aufweisen. Beispiel FFT für Lucas-Lehmer-Test (in Prime95):

Bei 32bit-FFT (so wie bei SETI@home) würde ein FP-wert etwa 3bit (Größenordnung stimmt, aber ich rechne es jetzt nicht extra aus *g*) des zu quadrierenden Wertes aufnehmen können um nach der FFT 6bit des Produkts zu liefern. Bei einem zu testenden Exponenten wie 27239923 (bei mir wird gerade 2^27239923-1 auf Primalität getestet) müsste die FFT ca. 9 Mio Elemente haben und dann z.B. mit der Größe 5*2^21 berechnet werden.

Doubles erlauben dagegen ca. 18-19 bit pro FP-Wert bei der obigen Berechnung. Dafür braucht die FFT mit nur etwa 1,5 Mio Elementen zu arbeiten (es sind zur Zeit 1536K). Das erfordert viel weniger FFT-Levels, Rechenoperationen und Speicher. Die 32bit-FFT muß etwa 7mal soviel Rechenoperationen durchführen und der Cache wird bei der Menge auch weniger ausgenutzt (es gibt "weniger Ergebnis pro 8 Byte").

Und alles wegen der Genauigkeit

i_hasser · 15.04.2005

Überleg mal was man alles an der CPU ändern müsste, damit man zB. 160Bit Floats bekommt. 80 Shadow-Regs müssten auf 160Bit verbreitert werden (bei AMD), alle Datenpfade überarbeitet und letztendlich auch die FPU aufgebohrt werden.

Würde also im Endeffekt alles was zur FPU gehört, bis auf RegRenaming, verdoppeln.

Dresdenboy · 15.04.2005

i_hasser schrieb:
Überleg mal was man alles an der CPU ändern müsste, damit man zB. 160Bit Floats bekommt. 80 Shadow-Regs müssten auf 160Bit verbreitert werden (bei AMD), alle Datenpfade überarbeitet und letztendlich auch die FPU aufgebohrt werden.

Würde also im Endeffekt alles was zur FPU gehört, bis auf RegRenaming, verdoppeln.

Ich bin hier am Lehrstuhl für Rechnerarchitektur. Du erzählst mir nichts Neues

Aber ich sage ja auch nicht, daß AMD jetzt die FPU ändern muß. Mir fällt auch gerade überhaupt kein sonstiger Prozessor (von general purpose bis zu Vectorprozessoren ein), der jetzt ein breiteres FP-Format als 80 bit hardwareseitig unterstützt. Per Software ist das alles kein Problem (aber natürlich auch langsamer). Ein Beispiel: http://www.apple.com/acg/pdf/oct3a.pdf

PuckPoltergeist · 15.04.2005

i_hasser schrieb:
Das Problem ist nicht wie gerundet wird, sondern bei zB. 1+1e-20 einfach die größe des Float-Wertes. Und bevor man 128Bit FPUs mit allem drum und dran einführt, kann man das auch emulieren - solange nur ein Bruchteil diese Genauigkeiten wirklich dringend benötigt.

Doch, es ist ein Problem, wie gerundet wird. Zum einen, um zu verhindern, dass auf unterschiedlichen Architekturen und bei unterschiedlichen Sprachen beim selben Algorithmus verschieden Werte raus kommen (ist z.B. bei SETI so), zum anderen kann es für verschieden Algorithmen auch vorteilhaft/notwendig sein, wenn nicht immer zum nächsten Wert gerundet wird. Genau deshalb müssen die Prozessoren auch die vier Rundungsmodi (nearest, down, up, to zero) unterstützen, wenn sie IEEI-754 kompatibel sein wollen.

i_hasser · 15.04.2005

Lies dir das nochmal in Ruhe durch, 1+1e-20 ist kein Rundungsproblem. Gibt immer 1, egal wie du rundest.

Itanium2: Rundung / double extended

Cadet

Grand Admiral Special

Grand Admiral Special

Captain Special

Redaktion☆☆☆☆☆☆

Vice Admiral Special

Cadet

Grand Admiral Special

Cadet

Vice Admiral Special

Grand Admiral Special

Cadet

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Vice Admiral Special

Cadet

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Grand Admiral Special

Ähnliche Themen

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆