Effinzienteste Art eine Map voller Vektoren zu transformieren



  • Sewing schrieb:

    aber ist denn ein

    std::array<std::array<float,4>,10> myArray
    

    notwendigerweise immer komplett sequentiell angelegt?

    Ja.

    Ebenso auch bei std::vector<std::array<float,4>> myArray . Nur dass du einmal vorne im Vector einen Pointer auf den gesamten Speicherbereich hast.

    Bei std::array<std::vector<float>,10> myArray dagegen sind die Vector-Objekte (d.h. vector-Länge, vector-Kapazität und vector-Datenpointer) sequentiell im Speicher. Die Vector-Daten sind dagegen nur einzeln sequentiell im Speicher. D.h. die Daten von myArray[0][0] bis myArray[0][size-1] liegen sequentiell im Speicher, die von myArray[1][0] bis myArray[1][size-1] ebenfalls, aber die einzelnen Datenbereiche der Vectoren haben nichts miteinenander zu tun.

    Sewing schrieb:

    die einzelnen unter-arrays können doch irgendwo auf dem Stack alloziert sein oder nicht?

    Nein.


  • Mod

    Sewing schrieb:

    aber ist denn ein

    std::array<std::array<float,4>,10> myArray
    

    notwendigerweise immer komplett sequentiell angelegt?

    Ja.

    die einzelnen unter-arrays können doch irgendwo auf dem Stack alloziert sein oder nicht?

    Nein, wieso sollten sie? Arrays sind kein magisches Gebilde. Das sind ganz normale Objekte, wie alle andere auch. Bei einem array<float, 4> sind die vier floats auf jeden Fall sequentiell. Das wundert dich nicht, oder? Wieso wundert dich dann, dass bei einem Array von Arrays die inneren Arrays sequentiell liegen?

    Der entscheidende Unterschied zwischen array<vector<float>> (mehrere Sequenzen verteilt im Speicher) und array<array<float>> (mehrere Sequenzen sequentiell im Speicher): Das Array ist sein Inhalt. Da wo das Array ist, ist auch sein Inhalt, die beiden sind ein und dasselbe. Der Vector ist nur ein Verweis auf seinen Inhalt. Der Inhalt kann und wird ganz woanders sein als die Verwaltungsdaten des Vectors.



  • Du mißverstehst etwas mit dem Stack.
    Daher wiederhole ich mal die Aussage:

    Arcoth schrieb:

    Das ist ziemlich leicht misszuverstehen, IMO. tuple**/array** hält Elemente in-place, i.e. in dem Speicher, der für das tuple**/array** selbst alloziert wurde. Damit vermeidet man den Overhead einer zusätzlichen Indirektion.

    Aber die Elemente liegen dann alle am Stück im Speicher.



  • Die Map besteht aus 5 Einträgen und jeder mapped-type hat dann ein paar tausend Einträge

    Du hasst nen dyn. Array aus fixen tuples von floats
    Dein Ergebnis ist wiederum ach nen dyn. Array mit selber grösse vom Ausgangs-Array aus fixen tuples aus floats.

    Das schreit formlich nach GPU, wenn die Arrays groß genug sind und die Berechnung komplex genug(Daten-Übertragung vs. compute zeit)
    Schon mal über ne Lösung auf OpenCL/Cuda/OpenGL/Vulkan Basis nachgedacht?
    Bei idealen GPU Bedingungen kann sogar der integrierte Intel HD chip gegenüber der CPU was bringen.

    Ciao ..


Anmelden zum Antworten