C++Guns – RoboBlog blogging the bot

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.

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.

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.

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

As I told you in my last post, Fortran sucks! This is the C++ Version and its only half as long.

#include <iostream>
#include <limits>
#include <cmath>
using namespace std;

template<typename Func> 
void test(Func func, string funcname, double a, double b, double x) {
  double res = func(a,b);
  cout << funcname << "(" << a << "," << b << ") = " << res << "\n";
  
  if(isnan(x)) {
    if(not isnan(res)) {
      cout << "But should be " << x << "\n";
    }
  } else if(res != x) {
    cout << "But should be " << x << "\n";
  }
}

int main() {
  double NaN = numeric_limits<double>::quiet_NaN();
  test(min<double>, "min", -3.0, NaN, -3.0);
  test(min<double>, "min", NAN, -3.0, -3.0);
  test(min<double>, "min", NAN,  NAN, NAN);
  
  test(max<double>, "max", -3.0, NAN, -3.0);
  test(max<double>, "max", NAN, -3.0, -3.0);
  test(max<double>, "max", NAN,  NAN, NAN);
}

The ugly procedure pointer is replaced with a simple template. But std::min() and std::max() are also template functions. So we must give the compiler a hint which one we want. We want std::min() for doubles. The code is fine, nothing more to say. Except it dosent work as expected ;)

Also Leapfrog ist voll cool. Es berechnet nicht Ort und Geschwindigkeit zum selben Simulationszeitpunkt, sondern versetzt. Frei nach dem Quantenprinzip, dass nicht Ort und Geschwindigkeit gleichzeitig mit beliebiger Genauigkeit gemessen werden kann.

Das Beispiel ist im ekligen C Code überhaupt geschrieben. Zeit es umzuschreiben.
Interessanterweise ist die C++ Version mit t_max=1000000 mit 6.8sec statt 8.4sec sogar um 20% schneller. Ich denke es liegt an den Schleifen die besser optimiert werden können, da die Anzahl der Iterationen fix zur Compilezeit ist. Und diese Information durch die constexpr size() Funktion des std::array Containers auch dem Compiler bekannt ist. Im Gegenzug zur C Version. Wo die Anzahl zwar auch fix zur Compilezeit ist, aber durch eine Laufzeit Variable n im Programm umher gereicht wird. Sonst ist der Code ja gleich.

Anbei die erste C++ Version und der C Code als Vergleich. Mehr wird folgen

inverse_square.c

inverse_square_part1.cpp

[1] https://de.wikipedia.org/wiki/Leapfrog-Verfahren
[2] https://www.physics.drexel.edu/students/courses/Comp_Phys/Integrators/leapfrog/