Array Klasse



  • 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