3. STL-Performance & Boost lib -> ja oder nein?

STL-Performance & Boost lib -> ja oder nein?

  • N

    afaiko schrieb:

    Und jetzt im gesamten code meine datenstrukturen zu ändern nur weil mein container zu langsam ist bzw. die methoden die darauf laufen das wäre doch blödsinn oder?

    Ich würde so was machen:

    #include <map>
typedef std::map<MyClass> ClassMap;

// verwende im Projekt das Typedef

    Nun kommst du nach ernsthaftem Profiling zu dem Schluss, dass eine eigene Implementierung schneller ist. Da du ein weiser Programmierer bist, hat deine eigene Containerklasse ein STL-konformes Interface. Nun musst du im Code genau zwei Zeilen abändern, nämlich:

    #include <SuperMap.hpp>
typedef SuperMap<MyClass> ClassMap;

// verwende im Projekt das Typedef

    Praktisch, oder? Du musst dir auf diese Weise keine Gedanken machen. Programmier zuerst mit der STL, allfällige Anpassungen sind dann später leicht realisierbar.

    0
  • ?

    ok...das ist interessant. ich denke darüber nach und danke euch schonmal für eure erfahrungswerte/Ideen. 🙂

    0
  • M

    [quote="tntnet"]

    Dravere schrieb:

    Beispielsweise bei einer std::list. Das ist eine einfach verkettete Liste.

    Ist sie nicht 🙂

    0
  • U

    afaiko schrieb:

    naja....einfach nur gleich STL machen ist ja nicht so - stelle dir vor ich merke dass meine Container bzw. das iterieren auf meinen containern oder sonstwas langsam wäre nachdem ich alles gecodet und geprofiled habe. Und jetzt im gesamten code meine datenstrukturen zu ändern nur weil mein container zu langsam ist bzw. die methoden die darauf laufen das wäre doch blödsinn oder?

    Allerdings bleibt einem ja nix anderes übrig...man weiß ja im vornherein nicht was einen erwartet...

    was machst du denn, dass du dann alles umschreiben musst?
    normalerweise sollte die schnittstelle schon gleich sein (iterator / op[] / ... - und das kannst du auch selbst ganz einfach machen - selbst mit nem c-array, das du nur einfach in ner klasse wrappst...

    wenn du das richtig machst, musst du später nur ein typedef und das include ändern...

    bb

    edit: sry, hatte davor net aktualisiert -.-

    0
  • N

    Im neuen Standard soll es std::forward_list geben, die im Gegensatz zu std::list einfach verkettet ist.

    Ich muss sagen, bis jetzt habe ich noch fast nie die Funktialität einer doppelten Verkettung benötigt...

    0
  • S

    Nexus schrieb:

    Ich muss sagen, bis jetzt habe ich noch fast nie die Funktialität einer doppelten Verkettung benötigt...

    dh du hast fast noch nie Elemente aus der mitte einer Liste entnommen?

    0
  • N

    Shade Of Mine schrieb:

    dh du hast fast noch nie Elemente aus der mitte einer Liste entnommen?

    Hmm doch, stimmt. Ich hatte das meistens nur beim Vorwärts-Iterieren, und dann gar nicht mehr dran gedacht, dass beim Entfernen das vorherige Element wieder neu verknüpft werden müsste. War wohl etwas voreilig, mein Einwand... 😉

    0
  • Administrator

    tntnet schrieb:

    Quatsch.

    Reine forward iteratoren werden verwendet, so sie algorithmisch Sinn machen. Beispielsweise bei einer std::list. Das ist eine einfach verkettete Liste. Ob ich die nun händisch mit Zeigern programmiere oder ein fertiges Template nehme macht normalerweise keinen Unterschied.

    1. Nein, es ist keine einfach verkettete Liste.
    2. Der OP redete nicht davon, dass er eine Liste selber implementiert, sondern im Vergleich zu Pointer Arithmetik. Also geht es hier um Arrays und Speicher, welcher an einem Stück ist. Natürlich kommt es wieder auf die Umstände an, also was man macht, aber deshalb habe ich ja auch "unter Umständen" hingeschrieben.

    tntnet schrieb:

    "Normalerweise" deshalb, weil es denkbar ist, dass ich bei einem speziellen Problem von der reinen Lehre einer einfach verketteten Liste abweichen kann und dadurch spezifische Optimierungen implementieren kann.

    Was ich im übrigen auch gesagt habe. Nur habe ich es mit unter Umständen ausgedrückt und später nochmal explizit darauf hingewiesen.

    tntnet schrieb:

    Häufig sind Iteratoren sogar Zeiger. Und wenn ich meinen Zeiger über einen typedef definiere, wird er nicht langsamer.

    Kann man so auch nicht stehen lassen. Dies ist nur bedingt der Fall und zwar nur bei Random Access Iteratoren. Deshalb habe ich auch geschrieben, dass die Random Access Iteratoren gleich schnell sein könnten.

    Lies also zuerst meinen Beitrag richtig, bevor du ihn einfach als Quatsch deklarierst.

    @afaiko,
    Zuerst die Funktionalitäten aufbauen. Optimieren tut man meistens erst am Schluss.

    Grüssli

    0
  • ?

    auf dem stack und schnelles 2d-array mit compilezeitkonstanter zweierpotenz als breite

    Was meint volkard eigentlich mit diesem sub-satz?

    0
  • C

    afaiko schrieb:

    auf dem stack und schnelles 2d-array mit compilezeitkonstanter zweierpotenz als breite

    Was meint volkard eigentlich mit diesem sub-satz?

    Statisches Array mit festen grenzen.

    int array[2][4];
    0
  • ?

    und warum 2er Potenz? Bringt das speed oder wie?

    0
  • V

    ich meinte tr1::array http://beans.seartipy.com/2006/12/10/getting-started-with-c-tr1-libraries/

    oder

    class FastArray2d<typename Data,size_t sizey,size_t sizex>
{
   std::vector<Data> dara;
   static const size_t realsizey=MetaCalcNectPowerOfTwo<sizey>::result;
   public:
...
   Data& get(size_t x,size_t y)
   {
      return data[y*realsizey+x];
   }
};

    das spart den mul-befehl im assemblercode und machts mit shift und add.

    0
  • C

    volkard schrieb:

    ich meinte tr1::array http://beans.seartipy.com/2006/12/10/getting-started-with-c-tr1-libraries/

    Da hab ich wohl auch was falsch verstanden 🤡

    0
  • ?

    Ohne näher auf deine Fragen einzugehen:
    Warum nimmst Du nicht boost::uBlas?
    http://www.boost.org/doc/libs/1_38_0/libs/numeric/ublas/doc/overview.htm
    Die ist optimiert und getestet.

    da sind aber nur basisfunktionen wie matrix*vektor drin oder? SO sachen wie QR- oder LU-Faktorisierungen oder Cholesky sind nicht implementiert kann das sein?

    0
  • T

    Das u von uBlas steht für Micro. Es ist also nicht alles vom originalen Blas drin.

    0
  • ?

    gibts sonst ein sehr gutes lin-Alg package welches durchaus mit Blas mithalten kann was performance und funktionalität angeht?

    0
  • ?

    Ich möchte Dir ggf. den Rat geben, bevor anfängst "Bitschubserei" zu betreiben, Dir Deine Algorithmen anzuschauen bzw. ein Profiling zu machen. Der Fehler liegt oft nicht bei dem Compilier oder den Libs, sondern beim Programmierer bzw. Algorithmus. Wenn Dir der bestehende Algorithmus zu langsam ist, dann verwende einen, der schneller ist (Bsp Super-LU vs Gauß). Alternativ parallelisiere, das machen die Libs nicht von sich aus. Du kannst die Boost gegen MPI linken und somit parallelisierte Algorithmen entwickeln.

    fpx

    0
Anmelden zum Antworten