Array Klasse



  • neue Version: array.hpp

    kleine Bugfixes und ein bisschen das Interface an die STL angepasst.
    IfThenElse wurde ausgelagert (if.hpp).

    Ich habe auch ein paar kleine Performancetests gegen die VC++7 Standard Library laufen lassen. Mein variableArray war immer eine spur schneller - allerdings waren die Beispiele nicht praxisrelevant.

    Aber ich bin zufrieden, denn mein variableArray ist also nicht signifikant langsamer als die VC++7 STL. Wenn jemand gegen STLPort testen könnte?

    Ich glaube ich werde bei Zeiten mal eine handvall anderer Container auf diese Art implementieren...

    Schade dass es so wenig Antworten von euch gibt - aber wenigstens keine Negativen. Also nehme ich an, dass es kein allzugroßer Käse ist, den ich hier mache.



  • Hallo!

    Um ganz ehrlich zu sein habe ich für meinen Teil hier nur nicht geantwortet weil ich stark bezweifle dass ich Dir helfen könnte.

    edit: Ich werde aber gerne im Laufe des Tages mal ein paar Tests mit STLport und gcc machen und dann die Resultate posten!



  • @nman:
    thx.

    Es war ja auch kein Vorwurf, sondern eine Feststellung 🙂

    btw: neue Version: array.hpp und if.hpp

    Ich habe neben ein paar bugfixes auch eine Verbesserung vorgenommen: eine Grow-Optionen.

    Man kann nun angeben ob das Array schnell wachsen soll (also Speicher 'verschwenden' um wenige Allokationen zu haben), normal wachsen soll (ungefähr so wie bisher) oder langsam wachsen soll (keinen Speicher zuviel allokieren -> Speicher sparen, dafür mehr Allokationen)

    ich hoffe es läuft auf dem gcc - denn momentan entwickle ich nur auf dem VC++7 😞



  • Dieser Beitrag wurde gelöscht!


  • Ich habe gerade die Version für gcc (3.2.3) und Comeau 4.3.3 BETA fertig 🙂
    blöde typenames und templates und this-> haben gefehlt...

    Danke für die Fehlerliste. Theoretisch müsste es jetzt passen!



  • Mein g++ kompiliert das jetzt tatsächlich.
    Jetzt stellt sich mir nur die Frage wie ich das testen soll, immerhin habe ich kein VC++7 als Vergleichsmöglichkeit...



  • nman schrieb:

    Mein g++ kompiliert das jetzt tatsächlich.
    Jetzt stellt sich mir nur die Frage wie ich das testen soll, immerhin habe ich kein VC++7 als Vergleichsmöglichkeit...

    Für mich sind nur die Ergebnisse im Vergleich zu anderen Standardlibraries interessant. Also schreib n kleines Programm, zB sowas:

    #include "array.hpp"
    
    #include <windows.h>
    #include <vector>
    #include <iostream>
    using namespace std;
    
    int const loop=10000000;
    
    int stdVector()
    {
      vector<int> vec;
      int size=0;
    
      for(int i=0; i<loop; ++i)
      {
        vec.push_back(i);
        size+=vec.size();
      }
    
      while(!vec.empty())
      {
        vec.pop_back();
        size+=vec.size();
      }
      return size;
    }
    
    int myVector()
    {
      ts::variablePodArray<int>::type vec;
      int size=0;
    
      for(int i=0; i<loop; ++i)
      {
        vec.push_back(i);
        size+=vec.size();
      }
    
      while(!vec.empty())
      {
        vec.pop_back();
        size+=vec.size();
      }
      return size;
    }
    
    int main()
    {
      cout<<"start\n";
      int size;
      DWORD start=GetTickCount();
      size=stdVector();
      DWORD end=GetTickCount();
      cout<<size<<endl;
      cout<<end-start<<endl;
      start=GetTickCount();
      size=myVector();
      end=GetTickCount();
      cout<<size<<endl;
      cout<<end-start<<endl;
    }
    

    und schau nach, wie sich mein Array gegen deine STL verhält.
    Auf meinem gcc (MinGW 3.2.3) schauts momentan schlecht aus 😞

    Wenn du auch die Standard STL hast die beim gcc dabei ist, dann Danke für die Mühe - aber die habe ich jetzt auch.

    Wenn du STLPort oder ähnliches hast - nur her mit den Tests 🙂



  • Bei meinem Test hängt alles an von Grower ab. Wenn er schnellt wächst ist meine Version schneller, wenn ich langsamer wachse, dann die STL.

    Ich muss mich wohl mal eingehender mit einem passenden Wachstumsalgo rumschlagen. Aber das pop_back() ist bei mir schneller als bei der STL - wie das wohl kommt?



  • Shade Of Mine schrieb:

    Für mich sind nur die Ergebnisse im Vergleich zu anderen Standardlibraries interessant. [...] schau nach, wie sich mein Array gegen deine STL verhält.

    Ah OK, ich dachte Du willst wissen wie sich die Performance mit unterschiedlichen Compilern verändert.

    Wenn du auch die Standard STL hast die beim gcc dabei ist, dann Danke für die Mühe - aber die habe ich jetzt auch.

    Wenn du STLPort oder ähnliches hast - nur her mit den Tests 🙂

    Ich habe auch STLport, muss aber wieder mal updaten, meine Version ist nicht mehr ganz taufrisch...



  • Hm, beim STLport kompilieren swappt mein Rechner leider so schlimm dass er absolut unbenutzbar wird, muss wohl noch etwas warten... 😞

    edit: Nachdem ich allerdings schon begonnen hatte die Zeit zu stoppen hier trotzdem das (unnütze) Ergebnis:

    nman: ~/c++/shadesArray > uname -a
    Linux method 2.6.0 #2 Mon Dec 22 23:45:22 CET 2003 i686 AMD Athlon(tm) Processor AuthenticAMD GNU/Linux
    nman: ~/c++/shadesArray > gcc -dumpversion
    3.2.3
    nman: ~/c++/shadesArray > echo $CXXFLAGS
    -march=athlon -O2 -pipe -fomit-frame-pointer -w
    nman: ~/c++/shadesArray > g++ -o stdArray stdArray.cpp ${CXXFLAGS}
    nman: ~/c++/shadesArray > g++ -o shadesArray shadesArray.cpp ${CXXFLAGS}
    nman: ~/c++/shadesArray > time ./stdArray
    276447232
    real    0m1.866s
    user    0m0.956s
    sys     0m0.308s
    nman: ~/c++/shadesArray > time ./shadesArray
    276447232
    real    0m6.878s
    user    0m3.947s
    sys     0m0.807s
    nman: ~/c++/shadesArray >
    


  • thx!

    ich liebe time - schade das windows sowas nicht hat 😞

    Bin auf einen Bug in erase() draufgekommen, dadurch wurde das pop_back() ziemlich lahm (und eigentlich Undefiniertes Verhalten verursacht)

    Weiters hängt es auch stark von den Allokierungsmethoden ab. Wenn ich zB den Block immer verdopple (so wie die STL) dann schaut das push_back auch shcon besser aus... Jetzt noch einen großen Block im Default Ctor allokieren und die Sache schaut gut aus...

    Muss mir mal eine gute Standardgröße überlegen... Momentan habe ich die Standardgröße auf 500 Elemente eingestellt - dies scheint mir bei den meisten meiner Programme eine passende größe zu sein. Die STL arbeitet aber scheinbar mit mehr...

    naja, so far: hier die neue Version: array.hpp und if.hpp



  • Hm, wo ist denn der util-Namespace? 🙄



  • nman schrieb:

    Hm, wo ist denn der util-Namespace? 🙄

    ups. sorry. Da habe ich wohl vergessen if.hpp zuuploaden :o

    IfThenElse habe ich in den util Namespace verschoben, weil ich vorhabe das ganze vielleicht auszubauen...

    Jetzt müsste if.hpp auch passen.

    sorry für die vergesslichkeit!



  • Shade Of Mine schrieb:

    IfThenElse habe ich in den util Namespace verschoben, weil ich vorhabe das ganze vielleicht auszubauen...

    Ich habs gesehen, bin schon gespannt! 🙂

    Jetzt müsste if.hpp auch passen.
    sorry für die vergesslichkeit!

    Tut es; kein Problem!

    nman: ~/c++/shadesArray > time ./shadesArray
    276447232
    real    0m4.147s
    user    0m1.670s
    sys     0m0.345s
    nman: ~/c++/shadesArray > time ./stdArray
    276447232
    real    0m2.786s
    user    0m0.997s
    sys     0m0.323s
    

    Es wird besser! 👍



  • wenn du bei

    Array()
          : sizeClass(500)
          {
            sizeClass.setSize(0);
            Allocator::allocate(value, sizeClass.getAlloc());
          }
    

    die 500 durch zB 1000 oder 1500 ersetzt, müsste mein Array schneller sein.

    aber wie gesagt, ich bin erst auf der suche nach einem vernünftigen startwert.

    ansonsten wäre es wohl am besten am anfang .reserve() aufzurufen - so dass die allokationen keinen unterschied mehr ausmachen.

    danke für die tests! 👍 👍



  • nman: ~/c++/shadesArray > sed -i 's/sizeClass(500)/sizeClass(1000)/
    nman: ~/c++/shadesArray > g++ -o shadesArray shadesArray.cpp ${CXXFLAGS}
    nman: ~/c++/shadesArray > time ./shadesArray
    276447232
    real    0m3.354s
    user    0m1.645s
    sys     0m0.318s
    nman: ~/c++/shadesArray > sed -i 's/sizeClass(1000)/sizeClass(1500)/' array.hpp
    nman: ~/c++/shadesArray > g++ -o shadesArray shadesArray.cpp ${CXXFLAGS}
    nman: ~/c++/shadesArray > time ./shadesArray
    276447232
    real    0m2.781s
    user    0m1.476s
    sys     0m0.265s
    

    Sieht so aus als wäre 1500 ein besserer Startwert als 1000; bei 2000 wird es wieder ein bisschen langsamer.
    Ich hab dann noch mit Werten zwischen 1500 und 2000 herumgespielt, aber bei den Tests die ich durchgeführt habe ist eigentlich immer 1500 am schnellsten gewesen.



  • nman schrieb:

    Ich hab dann noch mit Werten zwischen 1500 und 2000 herumgespielt, aber bei den Tests die ich durchgeführt habe ist eigentlich immer 1500 am schnellsten gewesen.

    Oh, danke. Dann werde ich wohl 1500 als startwert von GrowFast angeben... doch 1500 scheint mir ein bisschen hoch - da man normalerweise nicht so viele elemente hat. zumindestens stelle ich mir bei größeren objekten einen ziemliche platzverschwendung vor...

    großen dank!! 👍



  • Uh, jetzt wo Dus sagst: Frag mich nicht warum, aber weit bessere Resultate habe ich eigentlich bei 700, viel besser als bei 1000 oder 500:

    real    0m2.217s
    user    0m1.403s
    sys     0m0.247s
    

    Die Messdaten bei 400 sind auch recht ok:

    real    0m2.351s
    user    0m1.466s
    sys     0m0.264s
    

Anmelden zum Antworten