Wieder so ein C++ Blog, der aber in Wahrheit scheiß C Code verbreitet. Und dann erzählt er auch noch die Hälfte und macht unvollständige Angaben zu seinen Tests.
Es geht in dem Artikel darum, dass viele denken, dass floats kleiner und schneller als doubles sein. Kleiner sind sie, ja. Verbrauchen nur 4 Byte statt 8 Byte. Aber schneller sind sie nicht unbedingt. Sollten doch unsere heutigen CPUs mit genügen Hardware ausgestattet sein, um auch 64 Bit Zahlen genauso schnell zu verarbeiten. Na, wir werden sehen...
Endergebnis für ungeduldige:
Für kleine Datenmengen und IEEE Gleitkommazahlen verhalten sich bei meinen Tests floats und doubles gleich.
Verzichtet man auf Standard Zahlen und aktiviert fancy Optimierungen, wird man mit einem 1.5 bis 3.5-fachen schnelleren Programm belohnt, welches falsche Ergebnisse liefern kann.
Für große Mengen sieht die Sache anders aus. Dann wird der RAM Bus zum Flaschenhals.
Im ersten Teil übernehme ich sein Code und versuche die selben Ergebnisse zu erzielen. Im zweiten Teil schreibe ich das ganze nach C++ um. Leider gibt er nicht an, wie groß das Array sein soll und wie viele Iterationen gerechnet werden sollen. Also hab ich mal irgendwas eingestellt um ein paar Sekunden Laufzeit zu bekommen. Wenn man wie im original Artikel nur unter einer Sekunde misst, ist die Varianz zu hoch, und man weiß gar nichts.
Testfall:
AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
32Bit Debian
g++ 6.3.0
ARR_SIZE = 200000
NUM_ITER = 20000
Die Standardeinstellung für 64 Bit Systeme mit Optimierung ist SSE. Ich werde daher explizit auf den floating-point Coprozessor mit der Option -mfpmath=387 umschalten. Für SSE werde ich die Option -mfpmath=sse -msse2 benutzen.
Die Option -ffast-math kann übrigens falsche Ergebnisse liefern. Die exakten Vorgaben der IEEE Spezifikationen werden nicht eingehalten. Dafür sollte man ein schnelleres Programm haben.
Mittelwert von drei Berechnungen pro Einstellung. Alle Angaben in Sekunden.
| -O3 -mfpmath=387 | -O3 -mfpmath=sse -msse2 | -O3 -mfpmath=387 -ffast-math | -O3 -mfpmath=sse -msse2 -ffast-math | |
| float | 6.54 | 6.56 | 6.52 | 2.01 |
| double | 6.61 | 6.78 | 6.54 | 4.54 |
Also, dasss floats schneller sind als doubles, oder dass doubles schneller sind als floats kann ich in diesem Testfall nicht bestätigen. Bei mir sind sie im Grunde gleich schnell. Nur die Option -ffast-math bewirkt eine Geschwindigkeitsverbesserung um das 3-fache bzw. 1.5-fache.
Aber das kann von CPU zu CPU anders sein. Vor allen von microshit zu GNU.
Testfall 2:
Intel(R) Atom(TM) CPU N270 @ 1.60GHz
32 Bit Debian
g++ 4.9.2
ARR_SIZE = 200000
NUM_ITER = 20000
Mittelwert von drei Berechnungen pro Einstellung. Alle Angaben in Sekunden.
| -O3 -mfpmath=387 | -O3 -mfpmath=sse -msse2 | -O3 -mfpmath=387 -ffast-math | -O3 -mfpmath=sse -msse2 -ffast-math | |
| float | 21.1 | 18.9 | 21.1 | 6.19 |
| double | 22.2 | 22.2 | 22.2 | 31.6 |
Durch den Sparstrumpf Prozessor zeigt sich insgesamt eine höhere Laufzeit. Floats und doubles sind wieder in etwa gleich schnell. Nur die -ffast-math Option macht einen Unterschied. Für floats eine Verbesserung der Laufzeit wieder um das 3-fache. Und für doubles sehe ich sogar eine Verschlechterung um das 1.5-fache. Das müsste man jetzt versuchen zu erklären...
Testfall3:
AMD FX(tm)-9590 Eight-Core Processor
64 bit Debian
g++ 4.9.2
ARR_SIZE = 200000
NUM_ITER = 20000
Mittelwert von drei Berechnungen pro Einstellung. Alle Angaben in Sekunden.
| -O3 -mfpmath=387 | -O3 -mfpmath=sse -msse2 | -O3 -mfpmath=387 -ffast-math | -O3 -mfpmath=sse -msse2 -ffast-math | |
| float | 4.45 | 4.47 | 1.12 | 1.17 |
| double | 4.45 | 4.45 | 2.35 | 2.34 |
Die Laufzeit fällt insgesamt, verursacht durch mehr GHz Power. Bis auf -ffast-math sind floats und doubles wieder gleich schnell. Der Geschwindigkeitsvorteil für fast-math liegt wieder bei über 3.5-fach für floats und über 1.5-fach für doubles.
Endergebnis:
Für kleine Datenmengen und IEEE Gleitkommazahlen verhalten sich floats und doubles gleich.
Verzichtet man auf Standard Zahlen und aktiviert fancy Optimierungen, wird man mit einem 1.5 bis 3.5-fachen schnelleren Programm belohnt, welches falsche Ergebnisse liefern kann.
Für große Mengen sieht die Sache anders aus. Dann wird der RAM Bus zum Flaschenhals.
Warum verhält sich die Geschwindigkeit mit -ffast-math so unterschiedlich? Das muss man genauer untersuchen.
http://www.bfilipek.com/2012/05/float-vs-double.html