Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » STL-Performance & Boost lib -> ja oder nein?

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
14.04.2009, 12:04 Uhr
~afaiko
Gast


Hallo,

im Prinzip habe ich 2 Fragen die aber auf die Performance gehen.

Mein Hintergrund:
ich schreibe an einem numerischen code der möglichst performant (hinsichtliche Zeit) sein soll. Priorität liegt also auf Laufzeit aber sollte nicht gerade Speicherfressend sein. Also Prio 1 = Laufzeit, Prio 2 = Speicher.

1) Ich habe in vielen Tests gemerkt dass wenn ich z.B. die STL container und z.B. iteratoren und andere STL-Konstrukte verwende mein Code langsamer wird als wenn ich reine Arrays mit reiner "Pointer-Arithmetik" schreibe.
1.1) Kann das sein? Hat jemand ähnliches bemerkt?
2.1) Kann es also sein dass "C-lastiges C++" unter richtiger Verwendung schneller wäre als die Verwendung der STL?

2) Ich stolpere immer wieder über die boost-libs. Nun weiß ich dass da eine Menge Leute dran sitzen. Und boost ist so wie ich bis jetzt weiß die vorimplementierung für eine neue C++ Version.
2.1) Blödsinn oder stimmt das?
2.2) Falls 1.1) mit "ja" beantwortet wird - könnte es also sein dass auch hier die boost-libs etwas langsamer sind?
2.3) Was ist denn aber dann der Sinn der boost-libs? Schneller zu sein als die gewöhnlihce STL?
2.4) Kann man die boost-libs auch verwenden indem man nur header includiert? Also nicht zwinged immer gegen die lib linken muss beim kompilieren? Wenn der code z.B. jemanden gegeben wird möchte ich nicht dass er abhängig von boost erstmal noch boost installieren muss bzw. die lib kompilieren muss. Gäbe es einen Weg nur über einfaches einfügen der header auf boost zuzugreifen?

Danke euch vielmals
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
14.04.2009, 22:29 Uhr
Bruder Leif
dances with systems
(Operator)


Moin!

@1: Siehe Thread eins weiter unten. Mit demselben Jux quaele ich mich auch gerade rum. Die STL sind in erster Linie auf moeglichst universelle Verwendbarkeit getrimmt, und trotzdem noch schoen schnell. Dass eine exakt auf das jeweilige Problem zugeschnittene Loesung dabei schneller sein wird als der universelle Code, ist klar.
@2: Boost stand Pate fuer TR1, das ein paar der neuen Features von C++09 definiert. Boost selbst ist eine Art CPAN fuer C++, also eine Sammlung unterschiedlicher Bibliotheken fuer C++, das ja von Haus aus nicht gerade mit dem "Batteries included"-Praedikat glaenzt. Boost ist daher per se weder schneller noch langsamer als die STL, da es nicht hinsichtlich der Performance konkurriert, sondern was die Funktionalitaet angeht. Mit Boost bekommst Du jede Menge neue Features, die es in C++ "nur' mit der STL eben nicht gibt, z.B. Threads, Regulaere Ausdruecke etc.
Die meisten Boost-Klassen sind dabei tatsaechlich Template-Header und muessen (koennen!) nicht gelinkt werden. Nur die Regex- und ein paar andere Implementierungen brauchen eine eigene Lib.
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
15.04.2009, 12:14 Uhr
~afaiko
Gast


Erstmal danke für die Antwort!


Zitat:

Mit demselben Jux quaele ich mich auch gerade rum.



Und wie wirst Du vorgehen?

Was wäre dann eine sinnvolle Herangehensweise 1) oder 2) bzw. wie macht ihr (Du) das?
:
1) Möchte ich maximale Performance und nicht in die Gefahr kommen irgendwo nen bottleneck zu bekommen nehme ich keine(wenig) STL/Boost her.

2) Ich nehme STL/Boost her um viel funktionalität zu haben und profile dann. Im Falle von Bottlenecks muss ich Stellenweise optimieren bzw. evtl. Datenstrukturen oder sonstiges komplett ändern.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
15.04.2009, 20:59 Uhr
0xdeadbeef
Gott
(Operator)


Der generelle Konsensus ist, dass Optimierung erst am Ende kommt, das ist insbesondere für Mikrooptimierungen der Fall. Wenn du anfängst, ein Programm zu schreiben, ist erstmal wichtig, dass es tut, was es soll, und dass es dabei stabil läuft. Es ist dabei nützlich, auf das Laufzeitverhalten zu kucken, also wie der Code für größere Datenmengen skaliert, aber Mikrooptimierungen kommen erst ganz am Ende - dann nämlich, wenn du weißt, wo die Flaschenhälse auftauchen, die es zu entfernen gilt.

Prinzipiell empfiehlt es sich deswegen, mit einfach zu benutzenden und stabilen Konstrukten anzufangen, wie etwa den Containern der Standardbibliothek oder Boost-Bibliotheken. Man kommt schneller ans vorläufige Ziel, und man hat verlässlichen Code, der dir, sobald es an die Optimierung geht, ein ausreichend stabiles Umfeld gibt, diese in Ruhe umzusetzen - man muss sich nicht um Wechselwirkungen mit anderen, instabilen Codeteilen sorgen.

Auch ist es meiner Erfahrung nach oft so, dass Geschwindigkeitsprobleme gerade mit der Standardbibliothek aus einer suboptimalen Verwendung derselbigen entstehen. Zum Beispiel ist

C++:
std::vector<int> v;

for(int i = 0; i < 1000; ++i) {
  v.push_back(i);
}


auf etwas versteckte Weise sehr langsam, weil der Vektor dauernd erweitert werden muss - dies stellt man dann beispielsweise in der Optimierungsphase per Profiler fest, schlägt sich an die Stirn und schreibt zunächst

C++:
std::vector<int> v;

v.reserve(1000);

for(int i = 0; i < 1000; ++i) {
  v.push_back(i);
}


...und wenn die Anzahl Elemente wirklich von Vorneherein genau bekannt ist, fasst man sich dann erneut an die Stirn und schreibt

C++:
std::vector<int> v(1000);

for(int i = 0; i < 1000; ++i) {
  v[i] = i;
}


...wobei letzteres einen geringeren Geschwindigkeitsgewinn mit sich bringt als die erste Optimierung, es geht da vor allem darum, dass v.size() nicht dauernd angepasst werden muss. Wir hatten vor einer Weile einen selbsternannten "Optimierungsprofi" im Forum, der etwas mit dem ersten Codestück vergleichbares mit der Hashtable-Implementierung der SGI-STL abgezogen und daraus hergeleitet hatte, dass ein flaches 512MB-Array ein schnellerer Ansatz zur Zahlenspeicherung sei.

Wie dem auch sei, generische Bibliotheken bringen einen gewissen Overhead mit sich, allerdings ist der in der Regel nicht von großer Bedeutung und/oder vermeidbar, wenn man sich Gedanken darum macht, was im Hintergrund eigentlich passiert. Dieser geringe Nachteil wird durch die deutlich niedrigere Entwicklungs- und Debugzeit in aller Regel mehr als wieder wettgemacht, und wenn das Programm erstmal steht, kann man sich sehr viel leichter Gedanken darum machen, ob man statt std::vector<std::string> lieber boost::ptr_vector<std::string> oder char*[] benutzen will.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
16.04.2009, 13:35 Uhr
~afaiko
Gast


Also danke euch und vor allem vielen Dank an Deadbeef! Solche Meinungen/Gedanken/Erfahrungen sind Gold wert! Ich denke darüber nach und werde bei Gegebenheit auf diese Erfahrungen zurückgreifen
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: