C++Guns – RoboBlog blogging the bot

Ich habe gerade eine einfache Schleife mit 5 Zeilen geschrieben und auf einmal sah ich, dass das doch ein gutes Beispiel für funktionales programmieren wäre.
Gegeben ist ein Datenvector mit custom Typ und gesucht ist ein bestimmtes Datum und, falls vorhanden, davon ein bestimmter Wert. Die Schleife lässt sich von Hand so ausdrücken:

    struct Blah {
        size_t idx;
        int att;
    };

    vector<Blah> data { {2, -1}, {1, -1}, {5, 50}, {3, 10}};

    // skip -1
    size_t start = 0;
    for(size_t i=0; i < data.size(); ++i) {
        int att = data[i].att;
        if(att != -1) {
            start = data[i].idx;
            break;
        }
    }
    cout << "start " << start << "\n"; // print 5

Hier gibt es gleich eine ganze Reihe von Fehlerquellen. Von welchem Typ muss i sein, size_t oder int? Inkrement mit ++i oder i++ ? Ist der operator[] überhaupt vorhanden, und wenn ja auch effizient? Muss der Zugriff ueber const Referenz erfolgen? Und die Schleifen koennen wir beenden beim ersten Treffer, ja sicher oder ist das "break" zufällig da. Fuer alle das, muss man den Code Zeile fuer Zeile lesen und nachvollziehen und verstehen. Wie immer ist das "WAS und nicht WIE" Prinzip verletzte. Denn der Code sagt nicht, WAS er macht, sondern nur WIE. Ich hätte auch range-for nehmen können. Aber das ändert am Prinzip nichts.

Aus funktionaler Sicht ist die Schleife ja ein Muster fuer "find_if_apply" oder "apply_if_find" je nachdem ^^ Ob es in der funktionalen Welt so eine Funktion gibt, und wie sie genau heißt, weiß ich nicht. Aber ich probier mal meine eigene Version. Ich wäle den Namen "find_if_apply", da es schon eine C++ Funktion std::find_if gibt, und erweitere sie um eine "apply" componente.

template<class Container, class UnaryPredicate, class UnaryFunction>
void find_if_apply(const Container& data, UnaryPredicate p, UnaryFunction f) {
    for(const auto& x : data) {
        if(p(x)) {
            f(x);
            break;
        }
    }
}

size_t start = 0;
find_if_apply(data,
              [](const Blah& x) { return x.att != -1; },
              [&start](const Blah& x) { start = x.idx; }
              );
cout << "start " << start << "\n"; // print 5

Die Funktion find_if_apply nimmt zwei den Datensatz und zwei Funktionen. Die erste ist fuer find, und die zweite fuer apply.
Also die template Funktion selbst ist wirklich überraschend erstauling elegant einfach. Die Anwendung davon ist auch okay. Zwei einzeiler Funktionen sind noch lesbar.

Übrigends, std::find_if alleine hätte nichts geholfen. Da ein Iterator zurueck gegeben wird der wieder den Scope voll müllt und manuell auf Gültigkeit geprüft werden muss. Mit std::find_if wäre die Schleife und das if() weg gekapselt, aber gebracht hätte es nichts.

Noch eine Bemerkung: Die Variable idx in dem Beispiel ist explizit angegeben. Überwiegend kommt das in unseren Datenstrukturen und Algorithmen aber nicht vor. Dort ist die Position im Array der Index. Und schon funktioniert der funktionale Ansatz wieder nicht. Man könnte find_if_apply natürlich so erstellen und dokumentieren, dass das erste Argument der Lambdas der Laufindex ist. Aber nicht immer wird er auch in den Lambdas benötigt. Da mit Overloads und sonstige Tricks kommen macht alles wieder nur viel zu kompliziert. Noch dazu hat nicht jeder Container auch ein Laufindex. Bei Listen funktioniert es ist nicht, und da ist es dann Datenstruktur abhängig, wo der Index des Datums steht.

Erstmal ein Link zum Thema. Die sind selten. Copy, load, redirect and tee using C++ streambufs
Und noch einen A beginner's guide to writing a custom stream buffer (std::streambuf)

Also ich muss ganz ehrlich sagen, diese C++ iostream library ist einfach nur scheiße.
Total.... unmöglich damit was gescheites zu machen. Ich meine jetzt nicht std::cout oder die ">>" "<<" Stream Syntax. Nein, man muss das Geschichtlich sehen. Die I/O Library wurde designt, also C++ designt wurde. Ist also neben std::vector und std::string eines der ältesten Sachen in der Sprache. Anders als std::vector und std::string sind diese std::*stream Klassen einfach zu abstrakt geworden. Aber man muss das verstehen. Damals waren virtuelle Klassen und Templates neu, und wann es zuviel des Guten ist, muss man ja auch erst noch herausfinden. So finden sich in der Dokumentation gleich 11 Klassen um Zeug aus/in Datein/String/Streams zu lesen/schreiben. Ich ziehe hier absichtlich den Vergleich zu Qt und Fortran. Ja, Spass muss sein.
Bei Qt gibt es QIODevice als Basisklasse für unter anderem QFile und QBuffer und dazu QTextstream. Wobei QBuffer/Textstream hier ein normalen String meint, so wie es std::basic_stringstream ist. Unter Fortran gäbe es write/read(fhdl/string)...

Jetzt gibt es zwischen std und Qt ganz klare Unterschiede im Design. Fangen wir mit Qt an. Das ist am pragmatischsten.
* Ich will von einer Datei lesen/schreiben, nehm ich QFile.
* Ich will von einem String lesen/schreiben, nehm ich QBuffer/QTextstream.
* Ich will diese tollen Stream "<<" ">>" Operatoren, nehm ich QTextstream.
Und jetzt kommt der clou:
Egal ob man mit Dateien oder Strings arbeitet, die Stream Operatoren funktionieren mit QTextstream immer. Eben WEIL QIODevice als Basisklasse designt wurde.

So weit so gut.

In der C++ I/O Library gibt es Ähnliche Ansätze.
* Ich will von einer Datei lesen/schreiben, nehm ich basic_fstream.
* Ich will von einem String lesen/schreiben, nehm ich basic_stringstream.
* Ich will diese tollen Stream "<<" ">>" Operatoren, ja, sind schon dabei.
Und jetzt kommt der clou:
Egal ob man mit Dateien oder Strings arbeitet, die Stream Operatoren funktionieren immer. Eben WEIL basic_ostream und basic_istream als Basisklassen designt wurden.

Jetzt geht die c++ I/O Library weiter und macht noch die Unterscheidung, ob man nur lesen, nur schreiben, oder beides gleichzeitig will. Und wie es die Philosophie einer streng typ basierten Sprache so will, drückt man das in dem Typ einer Variable aus. Und nicht (nur) mit einer Laufzeit Variablen.

Aus diesem Grund gibt es neben basic_fstram auch basic_ifstram und basic_ofstram.
Und neben basic_stringstream auch basic_istringstram und basic_ostringstream. Und natürlich, neben basic_iostram auch basic_istram und basic_ostram. Damit sind 9 von 11 Klassen gefunden.

Schwachsinn? IMO! Damalig geiles Design um zu zeigen was in der Sprache steckt? Absolut!
Wir kommen zu den Templates.
Ahso, beinah hätte ich Fortran vergessen.
Bei Fortran gibt es write/read(fhdl/string).

Kennt ihr den Unterschied zwischen QString und QBytearray? Beides wird benutzt um "Text" darzustellen. Und QString ist sozusagen die Standardklasse bei Qt. Intern wird ein 16bit Character Type benutzt, statt dem sonst üblichen 8 bit. Das hat einfach den Grund, weil Qt Weltweit agiert. Und entsprechend auch Weltsprachen darstellen muss. Nun gibt es in der Welt viel mehr als 256 darstellbare Zeichen. Also wird ein 16bit Character genutzt.

Der C++ Erfinder hat das 1984 schon gesehen und die I/O Library entsprechend vorbereitet. Ob das die C++ Programmierer nun auch alle verstanden haben, sei mal dahin gestellt. Der Character Typ, ob 8bit oder 16bit, kann über Templates festgelegt werden. Die Anzahl der Klassen steigt also nicht, nur ihr Typ ändert sich.
So entspricht QBytearray std::string und QString entspricht std::wstring. Für alle vorgestellten std steram Klassen gibt es eine "normale "std::istraem" und eine "std::wistrem" Klasse. std::strinstream und std::wstringstream u.s.w.

Man sieht deutlich, dass die Information bei C++ im Type steckt. Ob pragmatisch oder schlecht sei dahin gestellt.
Bei Fortran gibt es write/read(fhdl/string) und hast du es mit ausländische Sprachen zu tun, hast du Pech gehabt.

Es fehlen noch std::basic_ios und std::ios_base. Bei Qt gibt es keine direkten Vergleichs Klassen, da die Implementierungsdetails versteckt sind. Aber bei C++ 1984 war das überhaupt noch kein Thema. Also, std::basic_ios ist eine Basisklasse von allen bisher vorgestellten std:: Klassen. Jede Funktion, die std::basic_ios bereit stellt, haben auch alle anderen Funktionen. Das sind hauptsächlich Funktionen für die Fehlerbehandlung oder den Status des internen Buffers.
Wie gesagt, das ist bei Qt alles weg-abstrahiert. Interne Buffer sind da irgendwo und machen ihren Job. Das ist für den Qt Anwender auch total egal. Hauptsache, man kann lesen/schreiben.
Aber C++ hat ja als Ziel, dass man alles tun kann. Also muss man auch die ganze Kontrolle haben. Und dennoch den Kompfor, dass man sich nicht selbst in den Fuß schießt. Naja.
Wenn bei Qt ein String NICHT in ein Integer konvertiert werden kann, dann passiert entweder garnichts, oder eine optionale logische Variable wird auf false gesetzt.
Bei C++ gibt es die Funktionen good() eof() fail() bad() oder Exception, um zu überprüfen ob alles geklappt hat. Bei Qt gibt es okay, oder nicht okay; zwei Möglichkeiten. Bei C++ gibt 16. Naja, fast. Wie immer ist C++ detaillierter. Wenn etwas nicht good() ist, dann ist es entweder eof() oder fail() oder bad(). Klar, oder?
Aber wenn eof(), dann ist das nicht unbedingt fail() oder bad(). Das Ende der Datei erreicht? Absolut kein Problem. Nun, zwischen fail() und bad() liegt der Unterschied, dass bad() schlechter als fail() ist. bad() impliziert fail(). Wenn bad() ist, dann geht es nicht weiter. Dann geht die Welt unter. Dann ist alles vorbei. Aber mit fail() koennen wir weiter leben. Eine Konvertierung von String nach Integer failt zwar, aber sonst ist alles okay und wir können weiter machen.

Wann genau welcher Fehler auftrifft, kann in der IObase Doku nachgelesen werden.

Nun gibt es seit C++ auch Exception. Alle Google Entwickler mögen hier jetzt bitte sterben. Exceptions bieten die Möglichkeit den Programmteil wo "alles ist gut", von dem Programmteil "Fehlerbehandlung" zu trennen. Liest man dann den Code von Oben nach Unten, liest man nur den Teil, der ausgeführt wird, wenn kein Fehler passiert. Nur das interessiert einem meistens.
Die Exceptions ignoriert man bei Qt komplett. Nun, das ist ein Weltweites Framework welches versucht es jedem recht zu machen. Es sei ihnen verziehen.
Bei C++ hat man, wie immer, die Wahl.

Kommen wir nun langsam zum Kern der Sache, warum ich mich damit beschäftige. Ich möchte einen XYZ Reader bauen, der stumpft pro Zeile drei Zahlen liest. Es sollen immer drei pro Zeile sein. Und ich möchte das mit pure C++ machen, weil Qt nicht überall installiert ist.
Das ist auch absolut kein Problem.

stream >> var1 >> var2 >> var3;

Das funktioniert bei C++ genauso wie bei Qt genauso wie bei Fortran. Nur da müsste man read() schreiben.
Aber was ist mit der Fehlerbehandlung? Wenn irgendwas schief läuft, dann will ich genau wissen, WAS und WO und WARUM es schief lief. Auf dumm herum Raten hab ich kein Bock. Lebenszeit und so.
Ja Scheiße, das funktioniert weder bei C++ noch bei Qt noch bei Fortran gut. Bei Fortran und Qt gib es zwar Statusvariabeln ob etwas schief lief, aber DAS etwas schief lief, muss man noch selbst prüfen. Bei C++ ist das DAS mit exceptions zwar automatisiert, aber es bleibt immer noch das WAS.
Und das WO, z.b. mit Zeilennummern, muss man alles noch selbst implementieren. Ich hätte gerne eine Fehlermeldung wie: "Datei xyz. Zeile: 123. String 'scheisse' kann nicht nach interger konvertiert werden". Ja dann ist alles klar. Und nicht "iostream error". Den Error kanntes dir sonst wo hin stecken.

Wir können dieses Verhalten natürlich selbst implementieren. Eine Zeile einlesen und parsen. Bei Fortran hat man gleich das Problem: Wie groß muss der Buffer sein? BUMM FAIL.
Bei Qt wird eine Kopie für den Buffer angelegt. BUMM Performance FAIL.
Bei C++ kapiert kein Aas wie er das implementieren soll. BUMM BRAINFAIL.

C++ soll performant sein. Und damit meinte ich nicht. "Lade die Webseite mit 4 Bildern und 3 Textzeilen in unter 10 Sekunde". Das ist für Gehirn entfernte Idioten. Ich meinte so etwas wie "Verarbeite eine Milliarden Buchstaben in einer Sekunde".
Und dazu gehört auch, dass Eingabe Daten nicht erst unnütz in einem extra Buffer geladen werden, sondern, dass gleich auf den Daten gearbeitet wird.

Und genau hier komme ich zur abstrakten Vorgehensweise von "Lese drei Zahlen pro Zeile ein". Ein Zeilenende ist durch ein \n gekennzeichnet. Es muss also erst ein Abschnitt gefunden werden, von wo bis zum nächsten \n gültige Daten vorliegen (unformatiertes lesen). Und dann erst kann auf diesem Abschnitt versucht werden, formatiert zu lesen. Also 3 Zahlen zu extrahieren. Diese Erkenntnis selbst, ist für viele schon Brainfuck genug.

Es sollen also folgende Fehler erkannt werden.
EOF bevor 3 Zahlen fertig gelesen wurden.
Newline char bevor 3 Zahlen fertig gelesen werden.
Konvertierungs Fehler von String nach Zahl.

So, und wie wird das Umgesetzt?
Erstmal die Version, welche eine Zeile in ein String einliest und dann parst.
Datei werden die Daten nicht gespeichert, nur eingelesen, geparst und verworfen.
Testdatei mit 772MB, 28895639 Zeilen a 3 Zahlen.

Workrechner:
real 0m44.049s
user 0m43.892s
sys 0m0.176s
17.55 MB/s

real 0m44.965s
user 0m44.760s
sys 0m0.216s
17.16 MB/s

Heimrechner:
real 2m0.688s
user 1m58.776s
sys 0m1.228s
6.38 MB/s

real 1m54.953s
user 1m54.172s
sys 0m0.628s
6.66 MB/s

Wir haben also ein Durchsatz von 17 MB/s bzw. 6 MB/s

std::ifstream ss(fileName);
if(!ss.is_open()) throw();
try {
  ss.exceptions(std::ios_base::failbit);
  for(size_t i=0; i < n and ss.good(); ++i) {
    std::getline(ss, line);
    std::istringstream ss2(line);
    ss2.exceptions(std::ios_base::failbit);
    ss2 >> data[0];
  }
} catch(std::ios_base::failure& ex) {
...
}

Zwei Input streams zu erzeugen kommt mir wrong vor. Aber der eine liest unformatted und der andere formatted.
Aber der formated stream kann ja auf dem Buffer vom unformatted stream Arbeiten. Oder so ähnlich. Eigentlich, ist der newline character ein Zeichen fuer den formated stream. Und nun kann man std::ctype und die std::locale von std::istream so änderen, dass '\n' nicht als whitespace anerkannt wird. Damit es es möglich, Zahl für Zahl einzulesen aber bei '\n' ist schluss. Dummerweise muss man im dann von Hand noch '\n' und restliche whitespaces einlesen. Das führt wieder zu versteckte Fehler. Und die virtuellen Fehler sind eh Performance Killer. Das MUSS besser gehen.

Workrechner:
real 0m32.871s
user 0m32.600s
sys 0m0.276s
23.49 MB/s

real 0m32.776s
user 0m32.576s
sys 0m0.200s
23.55 MB/s

Heimrechner
real 1m37.050s
user 1m33.396s
sys 0m1.512s
7.95 MB/s

real 1m39.499s
user 1m31.360s
sys 0m1.524s
7.76 MB/s

Immerhin von 17 auf 23 bzw. von 6 auf 7 MB/s hoch.

So, habe mit mmap die Inhalt direkt ueber den Speicher zugreifbar gemacht. Zum convertieren nehme ich std::strtod und bals std::from_chars. Die arbeiten direkt auf dem Speicher. Kein dummen rumkopieren in irgendwelche Buffer mehr. Dann schaun wir mal:

Heimrechner
real 0m33.893s
user 0m31.112s
sys 0m0.876s
22.77 MB/s

real 0m30.617s
user 0m29.564s
sys 0m0.356s
25.21 MB/s

Nu schau sich das mal einer an. Von 7 MB/s auf 25 MB/s hoch. Faktor 4 schneller. Dann müsste mein Workrechner locker mit 60 MB/s arbeiten. Mit eingeschalteter Compiler Optimierung ist sogar noch etwas mehr drin.

Der Cluster parst bei eingeschalteter Optimierung die 772 MB in 9.6sec. Das macht stolze 80.4 MB/s!