Wie langsam und suboptimal ist die STL wirklich?
-
Abgesehen von vielen Negativen Meinungen über C++ in den Kommentaren dieses Artikels: http://www.osnews.com/comments/20381?view=flat&sort=&threshold=0,
wurde auch explizit erwähnt das die STL veraltet und langsam sei. Dabei wurde diese Implementierung als Referenz genannt: http://www.ultimatepp.org/wwwcomparison$en-us.htmlJetzt würde mich interessieren wie 'schlecht' die STL wirklich ist und welche sinnvolleren Alternative es gäbe (innerhalb von C++ natürlich).
-
Was ist denn "die STL"? Da sind jede Menge Sachen drin. Die meisten Container sind von der Performance, vorausgesetzt, man übersetzt im Release-Mode, mit Standard-C Arrays/Konstrukten gleichwertig.
Mal ganz davon abgesehen gibt es auch nicht "die STL". Jeder Compilerhersteller hat unterschiedliche Implementierungen. Solange sie sich mit den im Standard definierten Anforderungen decken, ist das auch okay.
Das einzige, was man der STL vielleicht vorwerfen kann, ist das viele Klassentemplates etwas zu fette Interfaces habe. Freie Funktionen die man auf alle Container anwenden kann, wären vielleicht besser gewesen. Das extremste Beispiel hierfür ist wohl std::basic_string<>...
-
Für mich relevant wäre wohl die Implementierung von Microsoft (Visual Studio 2005), Qt4 (ist zwar nicht direkt STL, aber sehr ähnlich) und was unter Linux mit gcc verfügbar ist.
-
Wo hast Du denn einen Performanceengpass?
-
Naja ...
http://www.ultimatepp.org/wwwcomparison$en-us.html schrieb:
In order to demonstrate advantages of Ultimate++ (!!!),
we (!!!) have reimplemented some examples of other libraries.Wo soooo viel Absicht durchscheint, bezweifele ich mal die Objektivität...
Gruß,
Simon2.
-
Simon2 schrieb:
Naja ...
http://www.ultimatepp.org/wwwcomparison$en-us.html schrieb:
In order to demonstrate advantages of Ultimate++ (!!!),
we (!!!) have reimplemented some examples of other libraries.Wo soooo viel Absicht durchscheint, bezweifele ich mal die Objektivität...
Gruß,
Simon2.
Nach kurzem Überfliegen des Benchmarkcodes würde ich vermuten, dass der Geschwindigkeitsgewinn zum größten Teil der fehlen Move-Semantik im STL-Code geschuldet ist. Ab gcc 4.3 unterstützt der Compiler auch rvalue-Refernzen - ich weiß aber nicht, ob die mitgelieferte Standardbibliothek diesbezüglich bereits wenigstens rudimentär erweitert wurde. Es wäre zweifellos interessant, wie groß der verbleibende Geschwindigkeitsvorteil dann ist.
Ein paar Kleinigkeiten würde ich bemängeln (etwa dass das STL-map-Objekt nicht lokal zu BenchSTL ist, im Gegensatz zur NTL-Version; das könnte ein zusätzliches Register kosten was bei x86 teuer wäre - ich bezweifle aber, dass das einen Geschwindigkeitsgewinn dieser Größenordnung erklären würde). SO oder so ist der angewendete Stringalgorithmus ineffizient und dort dürfte der größte Teil der Zeit verschwendet werden.