Unterstützt der Raspberry Pi Hardware Floating Point?

Es gibt einige Artikel, die besagen, dass es am besten ist, Soft-Float-Algorithmen auf ARM-Geräten zu verwenden, da nur sehr wenige ARM-Chips über Hard-Float-Coprozessoren verfügen. Hat das RPi also eine Unterstützung für harte Posen? Wenn ja, ist es schneller, dass weiche Schwimmer? (Es sollte sein, richtig?)

Nach den Fragen und Antworten , verwendet die Himbeere Pi einen ARM - 11 - Chip mit Gleitkomma - Unterstützung:

Welchen SoC verwenden Sie?

Der SoC ist ein Broadcom BCM2835. Dieser enthält einen ARM1176JZFS mit Gleitkommazahl und 700 MHz sowie eine Videocore 4-GPU. Die GPU unterstützt die Wiedergabe in Blu-ray-Qualität mit H.264 bei 40 MBit / s. Es verfügt über einen schnellen 3D-Kern, auf den mit den mitgelieferten OpenGL ES2.0- und OpenVG-Bibliotheken zugegriffen werden kann.

Dies ist schneller als Soft Float (wenn nicht, wäre ich erstaunt!). Auf Systemen ohne Hardwareunterstützung ist es jedoch oft besser, die Festkommaverarbeitung zu nutzen, wenn Sie den durch Floating gebotenen Bereich nicht speziell benötigen Punktgenauigkeit.

Es hat Hardware-Gleitkomma-Unterstützung. Soweit mir bekannt ist, ist dies (noch) nicht in der Standard-Debian-Distribution verfügbar, die für das RPi bereitgestellt wird. Ich bin mir bei Arch nicht sicher, obwohl ich mir vorstellen kann, dass es bald soweit sein wird, wenn sie keine Unterstützung haben.

Ich habe Gentoo auf meinem RPi, also habe ich alles standardmäßig mit Unterstützung für Hard Float kompiliert. Es ist schnell :)

CFLAGS="-O2 -pipe -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"
CXXFLAGS="${CFLAGS}"
CHOST="armv6j-hardfloat-linux-gnueabi"

(distcc und cross-compiling werden natürlich ausgiebig genutzt!)

Hat das RPi also eine Unterstützung für harte Posen?

Ja, speziell (auf dem Original-Pi) VFPv2.

Wenn ja, ist es schneller, dass weiche Schwimmer?

Ja

Es gibt einige Artikel, die besagen, dass es am besten ist, Soft-Float-Algorithmen auf ARM-Geräten zu verwenden, da nur sehr wenige ARM-Chips über Hard-Float-Coprozessoren verfügen.

Im Jahr 2007 war Floating Point on Arm ein Chaos, viele Chips hatten überhaupt keine FPU. Diejenigen, die dies taten, hatten oft eine von mehreren verschiedenen und inkompatiblen. Der schlechtere Debian-Arm (einer der wichtigsten Linux-Distributionen zu dieser Zeit) wurde aus historischen Gründen für eine FPU namens FPA gebaut, die nur sehr wenige Chips hatte und sich hauptsächlich auf die Kernel-Emulation für Gleitkommazahlen stützte (Software-Gleitkommazahlen sind langsame, kernel-emulierte Gleitkommazahlen) ist langsamer). Ich denke, die Situation in anderen Distributionen war ähnlich, aber das sehe ich nicht positiv.

Angesichts der Unordnung zu der Zeit wurde entschieden, dass die beste Option darin bestand, einen EABI-Port unter Verwendung der Basisversion (Soft-Float-Version) von EABI zu erstellen. Dieses ABI wurde so konzipiert, dass der Code das Basis-ABI verwenden und optional die FPU verwenden kann. Die Idee zu dieser Zeit war, dass der Kern der Distribution mit Software-Fließkommazahlen erstellt werden sollte und dass dann spezifischer Code, der stark mit Fließkommazahlen verwendet wurde, mit Hardware-Fließkommazahlen erstellt werden konnte, aber immer noch die Basis-ABI (soft float) verwendet. Dieser Hafen war in der Debian-Welt als "Armel" bekannt.

Das Bit "Spezifische Pakete, die mit Hardware-Gleitkommazahlen erstellt wurden" hat jedoch nicht wirklich funktioniert. In der Praxis machten sich nur wenige Pakete die Mühe, so etwas zu tun, und es gab auch den Aufwand für das Umstellen von Werten zwischen Ganzzahl- und Gleitkommaregistern.

Schneller Vorlauf bis 2011 und die Situation hatte sich erheblich geändert. Arm hatte VFP aggressiv vorangetrieben, und die große Mehrheit der "Anwendungsprozessoren" (wie man sie in Mobilfunktelefonen und ähnlichen Geräten findet) hatte es übernommen. Eine Reihe von großen Linux-Distributionen (zumindest Debian, Ubuntu und Fedora anfangs, später) entschieden sich dafür, Ports mit Hardware-Fließkommazahlen und dem Hard-Float-ABI zu erstellen. Unglücklicherweise für den Pi stellten diese Distributionen (die zu dem Zeitpunkt, als der Pi veröffentlicht wurde, die Vollendung erreichten) ihre minimalen Hardwareanforderungen als ARMv7 mit VFPv3_d16 ein, so dass sie nicht auf dem Pi liefen.

Also begannen Pi-Fans damit, an pi-spezifischen Distributionsvarianten zu arbeiten, die Hardware-Fließkommazahlen und das Hard-Float-ABI verwendeten, aber mit Compiler-Einstellungen erstellt wurden, die auf dem pi laufen würden.

Seit dem 18. September 2012 unterstützt Arch Linux ARM auch Hard Float. Lesen Sie diese Ankündigung:

Heute öffnen wir die neuen armv6-Repositorys für Festplatten für die Öffentlichkeit. Alle Pakete wurden für die Unterstützung der VFP-Gleitkommaeinheit entwickelt, die im Raspberry Pi und in Via APC-IO verfügbar ist. Da es keinen Upgrade-Pfad zwischen dem armv5-Soft-Float-Repository und dem neuen armv6h-Repository gibt, haben wir auch ein neues Installations-Image für den Raspberry Pi veröffentlicht. Der Link zum Bild ist auf der Installationsseite für den Pi auf unserer Hauptseite verfügbar. Dieses Image ist auch für systemd anstelle von sysvinit und initscripts eingerichtet, sodass die Startzeiten kürzer sind und die Installation zukunftssicher für Änderungen ist, die in Arch endgültig werden.

Arch Linux ARM Raspberry Pi

Ja, wie schon andere gesagt haben, hat der Raspberry Pi eine harte Schwimmunterstützung. Überprüfen Sie das Betriebssystem Raspbian .

Raspbian ist eine inoffizielle Portierung von Debian Wheezy armhf mit angepassten Kompilierungseinstellungen, um optimierten "Hard Float" -Code zu erzeugen, der auf dem Raspberry Pi ausgeführt wird. Dies sollte eine erheblich schnellere Leistung für Anwendungen bieten, die Gleitkomma-Arithmetikoperationen stark nutzen.