Ich hab da mal was für euch.
Unterm Christbaum lag - oh welch Wunder - auch Computerliteratur, darunter das imho sehr gute Buch "C - kurz & gut" aus dem O'Reilly-Verlag (Autoren: Peter Prinz & Ulla Kirch-Prinz).
Nachdem ich das heute Nacht mal durchgelesen habe, bin ich dort auch auf diverse Datentypen mit festgelegter Breite gestoßen... darunter auch uint_fastN_t.
Nach einer kleinen Rätselratenrunde mit Eiffel56, was daran schneller sein möge als an int / long, beschlossen wir, dass ich einen "Benchmark" schreibe, wo ich mit folgendem Code:
http://nopaste.info/7db29fc0c1.html
auf amd64 (Athlon64 3200+) zu folgenden Ergebnissen komme:
Classic Long Long: 354s = 100,0%
Fast Long Long: 692s = 195,5%
Registered Classic Long Long: 345s = 097,5%
Registered Fast Long Long: 259s = 073,2%
Nun stellen wir uns die Frage, wieso diese Sondertypen zumindest in der freien Lektüre, die uns über den Weg lief, nicht begegnete, wo sich doch offensichtlich in bestimmten Fällen 25% Performance gewinnen lassen. Lediglich in mplayer, libboost und dergleichen findet sich der Datentyp in Verwendung wieder. Gibt es da noch nen bösen Haken?
Auch wäre interessant, wo diese Performance gegenüber einem klassischem Datentyp herkommt. Ich erkläre es mir immer noch mit einer CPU-Näheren Darstellung, da man ja sagt, dass moderne Rechenwerke mittlerweile nicht mehr viel mit i586 und co zu tun haben.
Und: Könntet ihr mal eure Ergebnisse posten?