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
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.
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.
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.
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.
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
> ü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.
> 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, ...
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.
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.
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