|
Anzeige
|
Gleitkommaaddierer in Hardware
Gast
#5243599
Hallo, ich komme bei zwei Fragen nicht weiter und zwar wieso es Sinnvoll ist ein Gleitkommaaddierer in Hardware zu implementieren... und Um wie viel Prozent ist die Hardwareimplemntierung im Durchschnitt schneller als die Softwareimplementierung (GCC Emulation)? Ich hoffe, Ihr könnt mir etwas helfen. Danke im Voraus Ehsab schrieb: > Um wie viel Prozent ist die Hardwareimplemntierung im Durchschnitt > schneller als die Softwareimplementierung Welche? Die auf der CPU oder die auf der GPU? In der Praxis müsste man auch die CPU genau kennen - auf einem 8-Bit 8051 ist die Floating Point Emulation erheblich langsamer als auf Cortex-M3. Ehsab schrieb: > ich komme bei zwei Fragen nicht weiter Hausübung? > und zwar wieso es Sinnvoll > ist ein Gleitkommaaddierer in Hardware zu implementieren... Weil es schneller ist? Das ergibt sich ja schon aus Frage 2 > und > Um wie viel Prozent ist die Hardwareimplemntierung im Durchschnitt > schneller als die Softwareimplementierung (GCC Emulation)? Ich glaube nicht, dass man das pauschal sagen kann. Eine Hardwareimplementierung kann schneller oder langsamer sein, genauso wie eine Softwareimplementierung je nach Programmierung und Hardware. Ehsab schrieb: > Um wie viel Prozent ist die Hardwareimplemntierung im Durchschnitt > schneller als die Softwareimplementierung (GCC Emulation)? Das ist exakt das gleiche Verhaeltnis, wie zwischen afrikanischen Schwalben und europaeischen Schwalben, die jeweils eine Kokosnuss tragen. SCNR, WK
Gast
#5243641
Ehsab schrieb: > Um wie viel Prozent ist die Hardwareimplemntierung im Durchschnitt > schneller als die Softwareimplementierung (GCC Emulation)? Da geht es oft nicht um Prozent, sondern um Faktoren 1..100. Konkret hängt das sehr an Hardware und Prozessor/Compiler, die man vergleicht. Durchschnittswerte zu bilden, ist so richtig sinnvoll nur, wenn die Verteilung sich halbwegs vernünftig durch eine Normalverteilung approximieren lässt. In allen anderen Fällen ist das statistische Spielerei und ohne Aussagekraft. Jan H. schrieb: > Ich glaube nicht, dass man das pauschal sagen kann. Eine > Hardwareimplementierung kann schneller oder langsamer sein, genauso wie > eine Softwareimplementierung je nach Programmierung und Hardware. was er wahrscheinlich meint ist: Wieviel schneller war ein 8087 gegenüber der FP-Software-Emulation auf dem 8086. bzw. die entsprechenden aktuelleren Pendants 80287 80387 usw.
Gast
#5243653
Ehsab schrieb: > Ich hoffe, Ihr könnt mir etwas helfen. https://en.wikipedia.org/wiki/X87 https://www.formelsammlung-mathe.de/prozentrechnung.html Mike B. schrieb: > Wieviel schneller war ein 8087 gegenüber der FP-Software-Emulation auf > dem 8086. Was allerdings darauf hinaus liefe, zwei Software-Implementierungen zu vergleichen. Denn der 8087 war ein spezialisierter Prozessor zur Realisierung von Fliesskommarechnung in Software. Nur steckte diese Software im Microcode-ROM. Demgegenüber arbeiten kombinatorische FP-Addierer und FP-Multiplizierer ohne Software/Microcode-Anteil und ohne Sequencing.
Gast
#5243683
natürlich ist auch die genaue Hardwarerealisierung entscheidend. Wenn man eine Pipelined Version implementiert, wo man in jedem Takt ein fertiges Ergebnis bekommt, kann man einen ganz schönen Durchsatz bekommen. Will man hingegen nur einmal zwei Zahlen addieren, so kann auch die Hardware Lösung langsam sein, da ja die CPU erstmal die Daten mit dem FPGA austauschen muss. tja schrieb: > Will man hingegen nur einmal zwei Zahlen addieren, so kann > auch die Hardware Lösung langsam sein, da ja die CPU erstmal die Daten > mit dem FPGA austauschen muss. Mit welchem FPGA? Eine Hardware-FPU hat zunächst nichts mit einem FPGA zu tun. Der AMD K6 hatte eine nicht gepipelinete FPU, die für Add/Mul 2 Takte benötigte. Das war ausgesprochen flott. Nur kamen genau zu dieser Zeit bewegte PC-Spiele auf, und zum ersten Mal in der Geschichte der PCs konnte man mit einer FPU-Pipeline in der Breite wirklich etwas anfangen.
Gast
#5243744
A. K. schrieb: > Mit welchem FPGA? Eine Hardware-FPU hat zunächst nichts mit einem FPGA > zu tun. stimmt, aber selbiger Thread wurde im FPGA Forum mit der Frage nach VHDL auch gestellt ;-) A. K. schrieb: > Der AMD K6 hatte eine nicht gepipelinete FPU, die für Add/Mul 2 Takte > benötigte. Das war ausgesprochen flott. Nur kamen genau zu dieser Zeit > bewegte PC-Spiele auf, und zum ersten Mal in der Geschichte der PCs > konnte man mit einer FPU-Pipeline in der Breite wirklich etwas anfangen. Das war aber schon früher so. Der Pentium war der erste Prozessor, bei dem die FPU dafür schnell genug war. Das erste größere Spiel, das eine FPU dann auch vorausgesetzt hat, war Quake.
Gast
#5243768
Ich hatte meine erste FPU 80C387 gekauft, damit Windows schneller läuft. Bei der Gelegenheit lernte ich, nicht alles zu glauben, was Verkäufer einem erzählen. Stefan U. schrieb: > Ich hatte meine erste FPU 80C387 gekauft, damit Windows schneller läuft. Wobei ich mal jemanden kannte, der sich für recht viel Geld einen 387 Coprozessor leistete, nur zum den dann 90° verdreht in den PGA Sockel zu wuchten. Irgendwann kam Intel auf die Idee, die Sockel so zu bauen, dass man das ohne Hammer nicht zustande brachte. Wieviele (Co-)Prozessoren wohl bis dahin diese traurige Schicksal ereilte? Stefan U. schrieb: > Ich hatte meine erste FPU 80C387 gekauft, damit Windows schneller > läuft. > > Bei der Gelegenheit lernte ich, nicht alles zu glauben, was Verkäufer > einem erzählen. über 1-2MB mehr RAM hätte WIndows sich mehr gefreut
Gast
#5243848
> über 1-2MB mehr RAM hätte WIndows sich mehr gefreut
Ja, aber davon hatte der Verkäufer wohl gerade keine übrig.
Ich schon ganz froh, dass man heute nicht mehr speziell für das
Betriebssystem die Hardware aufrüsten muss. Denn letztendlich ist das BS
genau wie die Hardware ja nur Mittel zum Zweck, ein Anwendungsprogramm
laufen zu lassen. Also sollten dessen Anforderungen im Vordergrund
stehen.
Gast
#5243902
Stefan U. schrieb: > Ich schon ganz froh, dass man heute nicht mehr speziell für das > Betriebssystem die Hardware aufrüsten muss. Muss man nicht???
Gast
#5243909
> Muss man nicht???
Nö. Wann hast du zuletzt einen PC oder Laptop gesehen, auf dem Linux
oder Windows nicht laufen kann? Ich kann mich nicht mehr erinnern, so
lange ist das her.
Stefan U. schrieb: > Nö. Wann hast du zuletzt einen PC oder Laptop gesehen, auf dem Linux > oder Windows nicht laufen kann? Linux und Laptop kann immer noch schwierig sein. Treiber für WLAN, Touchpad, Audio, ...
Gast
#5243923
Ja ok, aber das ist dann eher eine Frage der Kompatibilität, nicht der Aufrüstung.
Gast
#5243931
Stefan U. schrieb: > Wann hast du zuletzt einen PC oder Laptop gesehen, auf dem Linux > oder Windows nicht laufen kann? Ömmm... Also ich habe hier einige Rechner zu stehen die hervorragend die ihnen zugedachten Aufgaben bewältigen, denen ich aber Windows 10 nicht antun würde.
Gast
#5244101
Ehsab schrieb: > Hallo, > > ich komme bei zwei Fragen nicht weiter und zwar wieso es Sinnvoll > ist ein Gleitkommaaddierer in Hardware zu implementieren... > > und > > Um wie viel Prozent ist die Hardwareimplemntierung im Durchschnitt > schneller als die Softwareimplementierung (GCC Emulation)? > > Ich hoffe, Ihr könnt mir etwas helfen. > > Danke im Voraus Schreib den algorithmus auf und schau dir eine Implementierung in Pseudoassembler an, zägle die cycles. Dann schau auf das Blockbild eines Hardwareadders an und schreibe den Algorithmus als ressorrce scheduling plan auf, zähle jetzt die cycle für einen durchlauf. Wichtig ist, das du dir die einzelnen schritte des Adds und die Struktur einer Float-Zahl klar machst. Der Algorithmus muss also Schritte enthalten wie -Exponentenvergleich -Mantissenanpassung eines Summanden --subtraktion der Exponenten --bestimmung des nötigen mantissenshifts aus der ermittelnden Differenz --Shift. -Mantissenadd -Prüfen auf Überlauf -bei Überlauf Normalisierung .. Im blockbild muss erkennbar sein welche Hardwareblöcke parallel arbeiten könnten. Die Beschleunigung ergibt sich das mehrere Teiloperationen gleichzeitig ausgeführt werden könnten (hier eher nicht) oder Teiloperationen effizenter ausgeführt werden bspw Barrel-shifter statt bitshift. Am besten du machst mal ein paar experiemente für ein System mit Integrierte FPU indem du die Verlinkung der Hardwareunterstützung benchmarkmäßig ein- und ausschaltest. Und geh mal in eine Fachbibliothek und schau in den Büchern zur Rechnerarchitektur und Numerik nach.
Gast
#5244113
Da noch ein thread der sich mit ein paar details zum FPU-Benchmarking befasst: Beitrag "Floating Pointing Unit STM32F4"
Gast
#5244264
Stefan U. schrieb: > Wann hast du zuletzt einen PC oder Laptop gesehen, auf dem Linux > oder Windows nicht laufen kann? Willst du ernsthaft behaupten, alle Rechner die noch irgendwo rumstehen, haben 4 GB Ram und 100 GB Festplatte, wie für Windows 10 gefordert? Da stehen noch Millionen rum, auch in Betrieb, die davon weit entfernt sind. Georg
Gast
#5245283
Ich rede von halbwegs aktuellen Rechnern. Nicht von uralten Kisten (über 6 Jahre), für die man Aufrüst-Teile nicht einmal mehr kaufen kann. Antwort schreiben |
Anzeige
|
