C++ vektor

[glühbirne]

jokurt schrieb:

Die einzige überladene STL-Klasse ist std::array. Es gibt wirklich keinen Grund, das zu benutzen.

Genau andersherum: Mit std::array gibt es keinen Grund mehr, C-Arrays zu nutzen. Man hat nur fehlende Sicherheit und Wertsemantik.

Fuchs: Mach ein minimales Programm mit dem Benchmark und poste die Ergebnisse. Ich bezweifle nach wie vor, dass beides gleich schnell ist.

<>

[formanz]

glühbirne schrieb:

fehlende Sicherheit

Sicherheit hat man nur im Debug-Build. Und da können auch Array-Zugriffe überprüft werden, sonst hat man die falschen Tools.

glühbirne schrieb:

Wertsemantik.

Praktisch immer ein Fehler. Arrays zu kopieren sollte man vermeiden oder zumindest syntaktisch kenntzeichnen. C-Arrays unterstützen einen dabei.

.begin(), .end(), .size() sollte man sowieso durch std::begin, std::end, ::size ersetzen, C-Arrays unterstützen einen dabei.

C-Arrays können auch automatisch ihre Größe herausfinden, bei std::array besteht immer die Gefahr, sich um eins verzählt zu haben.

<>

[camper]

Bei einem 256-Byte großen Element dürfte die Containerwahl relativ unbedeutend für die Performance sein (bei einfachen iterativen Algorithmen). Der Vorteil von vector in Bezug auf bessere Cachlokalität ist dann einfach kaum noch gegeben, und der Speicheroverhead von Node-basierten Containern ist auch unbedeutend.

[Fuchs aus dem Wald]

glühbirne schrieb:

Fuchs: Mach ein minimales Programm mit dem Benchmark und poste die Ergebnisse. Ich bezweifle nach wie vor, dass beides gleich schnell ist.

<>

Liste:
START: 1370425812:811620
ENDE: 1370425812:811626
hier sind es 6 Mikrosekunden
Vektor:
START: 1370426056:420174
ENDE: 1370426056:420196
Hier sind es 22 Mikrosekunden

Ok es ist mit dem Vektor wirklich langsamer. Ich hatte das auf dem gesamten Durchlauf getestet jetzt nur auf den einzel Part. Und dann auch nur grob gerechnet.

[camper]

formanz schrieb:

glühbirne schrieb:

Wertsemantik.

Praktisch immer ein Fehler. Arrays zu kopieren sollte man vermeiden oder zumindest syntaktisch kenntzeichnen. C-Arrays unterstützen einen dabei.

Warum?

formanz schrieb:

C-Arrays können auch automatisch ihre Größe herausfinden, bei std::array besteht immer die Gefahr, sich um eins verzählt zu haben.

Nicht relevant in diesem Thread, schließlich geht es hier nicht um automatische oder statische Arrays, die ihre Größe aus einem Initialisierer ermitteln können.

[formanz]

@Fuchs:

formanz schrieb:

Wenn die Messung richtig gefaked ist, ist

std::vector<COLOR> colors;

langsamer, dann nimm

std::deque<COLOR> colors;

Das ist garantiert schneller.

Beachte, dass du auch auf die Member zugreifst.

camper schrieb:

formanz schrieb:

glühbirne schrieb:

Wertsemantik.

Praktisch immer ein Fehler. Arrays zu kopieren sollte man vermeiden oder zumindest syntaktisch kenntzeichnen. C-Arrays unterstützen einen dabei.

Warum?

Wertsemantik ist hauptsächlich sinnvoll als Member und da ist die Wertsemantik gegeben.

Nicht relevant in diesem Thread:
Rückgabewert -> Referenz auf Parameter (falls man Pech bei RVO hat)
Parameter -> const-Referenz oder Iteratoren

[Fuchs aus dem Wald]

Ich glaub um so mehr ich hier lese um so mehr muss ich leider sagen hier wird absoluter mist gecoeded ...
Also hier bei mir

[Youka]

Fuchs aus dem Wald schrieb:

Liste:
START: 1370425812:811620
ENDE: 1370425812:811626
hier sind es 6 Mikrosekunden
Vektor:
START: 1370426056:420174
ENDE: 1370426056:420196
Hier sind es 22 Mikrosekunden

Ok es ist mit dem Vektor wirklich langsamer.

Mit Erstellung des Vektors muss ein größerer Speicherbereich reserviert werden, was mehr Zeit kostet, als die wenigen kleinen Speicherbereiche deiner Liste. Das war's dann aber auch mit der Erstellung, folgend muss auch auf den Speicher zugegriffen werden und da punktet der Vektor ganz klar!

[Fuchs aus dem Wald]

Youka schrieb:

Mit Erstellung des Vektors muss ein größerer Speicherbereich reserviert werden, was mehr Zeit kostet, als die wenigen kleinen Speicherbereiche deiner Liste. Das war's dann aber auch mit der Erstellung, folgend muss auch auf den Speicher zugegriffen werden und da punktet der Vektor ganz klar!

Jop der Zugriff kommt erst später... ach ja das beste hab ich noch gar nicht erzählt.
Ich muss alle Daten von der liste in ein Array packen damit ich es überhaupt verschicken kann.
Jetzt fragt ihr euch sicher warum nicht gleich Array ... naja ich kenne die endgültige Größe ja nicht.
Aber Vektor ist da ja sooooooo viel umständlicher.

[camper]

Fuchs aus dem Wald schrieb:

glühbirne schrieb:

Fuchs: Mach ein minimales Programm mit dem Benchmark und poste die Ergebnisse. Ich bezweifle nach wie vor, dass beides gleich schnell ist.

<>

Liste:
START: 1370425812:811620
ENDE: 1370425812:811626
hier sind es 6 Mikrosekunden
Vektor:
START: 1370426056:420174
ENDE: 1370426056:420196
Hier sind es 22 Mikrosekunden

Ok es ist mit dem Vektor wirklich langsamer. Ich hatte das auf dem gesamten Durchlauf getestet jetzt nur auf den einzel Part. Und dann auch nur grob gerechnet.

Das sagt nicht viel aus, ohne zu wissen, was genau da getestet wurde. Diese Zeiten entsprechen ungefähr dem theoretischen Ergebnis, wenn für den vector ein Wachstumsfaktor von 1.5 angenommen wird (ohne Reservierung), der Aufwand der eigentlichen Speicherallokation gering ist und nur das usprüngliche Befüllen der Container gemessen wurde (und dafür intressieren wir uns ja eigentlich nicht so sehr).
Ansonsten ist eher zu vermuten, das
- unpassende Compileroptionen verwendet wurde, oder
- unpassende debug Einstellungen verwendet wurde (die Performance von Debug-Container kann sich erheblich - auch was die Komplexität angeht - von denen normaler Container unterscheiden), oder
- eine unpassene Messmethode verwandt wurde

[Fuchs aus dem Wald]

Messmethode hab ich doch gepostet.

[Furble Wurble]

Wes Brot ich ess, des Lied ich sing.
Da musst Du wohl durch.
Und das öffentliche Gezicke gegen die eigene Firma würde ich sein lassen!

Naja, wo wir schon Code sehen:
Das mit der Geschwindigkeit lasse ich mal dahingestellt.
Aber bei so einem Firelefanz wie diesem hier geht mir der Hut hoch:

struct COLOR{
  char col[256];
  COLOR* next;
};

COLOR* curr;
COLOR* first;

Konstruktor(){ curr = NULL; first = NULL}

if(!first){
    first = new COLOR;
    curr = first;
  }else{
    curr->next = new COLOR;
    curr = curr->next;
  }
  curr->next=NULL;	
}

Wieso hat eine Farbe eine Eigenschaft next ? Und wenn ich schon meine eigene Liste schreibe (haben wir schließlich alle mal), warum dann nicht als Template, sondern für jeden Typ eine eigene? Das ist ganz übler Stil - irgendwas zwischen C, C with classes und C++ ohne STL.

Ich würde noch ein Stück weiter gehen als formanz und sogar das eigene struct entfernen

typedef std::array<char, 256> COLOR;
  std::forward_list<COLOR> colors;

(und um Ihn zu ärgern habe ich sogar ein std::array eingebaut )

Damit schrumpft Eure Codebasis erheblich - allerdings ist natürlich die Lernkurve der Standardbibliothek auch nicht ganz zu verachten...
Spannend wäre noch zu wissen, wie gut sich Eure container mit den Algorithmen der STL vertragen...

[camper]

Fuchs aus dem Wald schrieb:

Messmethode hab ich doch gepostet.

Du hast nur gezeigt, dass du eine Zeit gemessen hast. Nicht, wovon diese Zeit abhängt.

[Fuchs aus dem Wald]

Ja stimmt. Aber ich kann nicht den ganzen Code zeigen. Ich müsste etwas mehr zeigen und ich will nicht so viel davon hier posten.

[Youka]

Fuchs aus dem Wald schrieb:

Ich muss alle Daten von der liste in ein Array packen damit ich es überhaupt verschicken kann.
Jetzt fragt ihr euch sicher warum nicht gleich Array ... naja ich kenne die endgültige Größe ja nicht.

Das heißt, es wird erst aus dem späteren Array gelesen und die Datenmenge kann x-beliebig groß sein?
Das hättest du auch gleich zu Anfang schreiben können, da dies stark die Liste begründet (Vorteile hatte ich bereits genannt).
Du musst nun allerdings nicht deine Liste in C Manier wie im ersten Post verwenden, sondern kannst in C++ queue verwenden.
Will heißen: Queue Elemente nach und nach einfügen -> Queue Größe abfragen -> Array mit gleicher Größe erstellen -> Elemente von vorne nach hinten aus der Queue entfernen und in das Array eintragen

[DocShoe]

Youka schrieb:

Das heißt, es wird erst aus dem späteren Array gelesen und die Datenmenge kann x-beliebig groß sein?
Das hättest du auch gleich zu Anfang schreiben können, da dies stark die Liste begründet (Vorteile hatte ich bereits genannt).
Du musst nun allerdings nicht deine Liste in C Manier wie im ersten Post verwenden, sondern kannst in C++ queue verwenden.
Will heißen: Queue Elemente nach und nach einfügen -> Queue Größe abfragen -> Array mit gleicher Größe erstellen -> Elemente von vorne nach hinten aus der Queue entfernen und in das Array eintragen

WTF? Mit std::vector hast du dann doch schon alles, was du brauchst.

[formanz]

Youka schrieb:

queue

aka deque. deque ist der Kompromiss zwischen forward_list und vector, bin nicht sicher, ob du dir dem bewusst bist.

@Furble Wurble: Ist wirklich jedes std::array<char, 256> ein COLOR-Block? Eine eigene Klasse ist mir da lieber (mit char[256], ein std::array führt zu {{{<data>}}}-Initializern -- ein weiterer Grund, weshalb std::array als Member sinnfrei ist).

Mit char werden übrigens nur 2^7-2 positive Werte garantiert, hier ist unsigned char[256] zu empfehlen.

[camper]

formanz schrieb:

Mit char werden übrigens nur 2^7-2 positive Werte garantiert

typischer off-by-one Fehler

[Furble Wurble]

formanz schrieb:

[@Furble Wurble: Ist wirklich jedes std::array<char, 256> ein COLOR-Block? Eine eigene Klasse ist mir da lieber (mit char[256], ein std::array führt zu {{{<data>}}}-Initializern -- ein weiterer Grund, weshalb std::array als Member sinnfrei ist).

Duck typing - ich habe da kein Problem mit. Das initialisieren mit '{{' '}}' kann ich auch verkraften. Aber std::array ist nicht das Thema dieses Threads.

[Fuchs aus dem Wald]

DocShoe schrieb:

WTF? Mit std::vector hast du dann doch schon alles, was du brauchst.

Ja so sehe ich das auch. Warum immer so umständlich, wenn es doch was gibt was genau das schon kann.