Kleine, aber brauchbare Vektor/Matrix Bibliothek
-
Ich habe vor einiger Zeit zwei Templates für Matrizen und Vektoren beliebiger (aber zur Compiletime feststehender) Größe programmiert. Das ganze ist C++ und benutzt boost. Vollkommen unoptimiert aber ziemlich klein. Vielleicht kannst du ja damit was anfangen: http://www.geloescht.net/allerlei/mv.zip
geloescht
-
Ist es schlecht die STL-Container zu benutzen?
(Wenn man Spiele Programmiert?)
-
Äh... nein. Aber es ist schlecht Standardcontainer zu benutzen wenn die Größe des Containers zur Compilezeit bekannt ist. Ansonsten hat die STL in den meisten Fällen auch das, was man braucht.
-
geloescht schrieb:
Äh... nein. Aber es ist schlecht Standardcontainer zu benutzen wenn die Größe des Containers zur Compilezeit bekannt ist. Ansonsten hat die STL in den meisten Fällen auch das, was man braucht.
Hmm. Ich würde das mit der Grösse nicht so pauschal sagen. Klar ist es schneller, aber man kann sich noch zusatzüberlegnugen machen, wie was wäre, wenn man doch eine Variable Grösse braucht irgendwann, aber auch der Zugriff ist sicherer und könnte irgendwann ein Problem geben.
Im übrigen würde ich mal sagen, dass die Geschwindigkeit nicht an der STL scheitert, sondern eher an anderen Teilen, die man optimieren kann und die STL spielt dann keine so grosse Rolle mehr.
-
drakon schrieb:
geloescht schrieb:
Äh... nein. Aber es ist schlecht Standardcontainer zu benutzen wenn die Größe des Containers zur Compilezeit bekannt ist. Ansonsten hat die STL in den meisten Fällen auch das, was man braucht.
Hmm. Ich würde das mit der Grösse nicht so pauschal sagen. Klar ist es schneller, aber man kann sich noch zusatzüberlegnugen machen, wie was wäre, wenn man doch eine Variable Grösse braucht irgendwann, aber auch der Zugriff ist sicherer und könnte irgendwann ein Problem geben.
Im übrigen würde ich mal sagen, dass die Geschwindigkeit nicht an der STL scheitert, sondern eher an anderen Teilen, die man optimieren kann und die STL spielt dann keine so grosse Rolle mehr.Die STL hat oft hinter der O notation versteckte (Geschwindigkeits)kosten. Alleine schon ein std::vector als member bringt
-eine indirektion mehr beim zugriff auf die elemente
-speicherverbrauch fuer den container selbst
-mehr fragmentierung des speichers
-vermutlich mehr cachemisses
...wenn man die stl verwenden will, dann sollte man das aufgrund von verlaesslichem code machen und nicht auf die performance schauen.
-
drakon schrieb:
Hmm. Ich würde das mit der Grösse nicht so pauschal sagen. Klar ist es schneller, aber man kann sich noch zusatzüberlegnugen machen, wie was wäre, wenn man doch eine Variable Grösse braucht irgendwann, aber auch der Zugriff ist sicherer und könnte irgendwann ein Problem geben.
Bei einem konkreten Problem weiß ich normalerweise ziemlich genau ob ich mich auf eine gewisse Dimension beschränke, oder ob das variabel sein muss. Und selbst wenn es nachher wider Erwarten variabel sein müsste, kann ich doch vorher eine nicht dynamische Datenstruktur dahinter packen. Das ist doch das Schöne an der Kapselung.
rapso schrieb:
Die STL hat oft hinter der O notation versteckte (Geschwindigkeits)kosten. Alleine schon ein std::vector als member bringt
-eine indirektion mehr beim zugriff auf die elementeDa ein std::vector IIRC den Speicher am Stück vorliegen haben muss, würde ich mal tippen, dass die Indirektion beim operator[] wegoptimiert wird.
-
Walli schrieb:
rapso schrieb:
Die STL hat oft hinter der O notation versteckte (Geschwindigkeits)kosten. Alleine schon ein std::vector als member bringt
-eine indirektion mehr beim zugriff auf die elementeDa ein std::vector IIRC den Speicher am Stück vorliegen haben muss, würde ich mal tippen, dass die Indirektion beim operator[] wegoptimiert wird.
leider nicht moeglich. der compiler kann nicht wissen wohin der pointer zeigt ohne erst den pointer auszulesen, weil der speicher zur laufzeit allokiert wird. ein memberarray hat hingegen einen festen offset innerhalb der klasse und es gibt nichtmal einen impliziten pointer darauf.
-
Ach okay. Jetzt weiß ich was Du meinst. Ich dachte wir reden über dynamisch angefordertes Array vs. std::vector.
-
Walli schrieb:
Ach okay. Jetzt weiß ich was Du meinst. Ich dachte wir reden über dynamisch angefordertes Array vs. std::vector.
Ich hab mir schon mit absicht das beispiel rausgepickt
bei dynamisch allokiertem speicher sollte eigentlich dann gleich schneller code enstehen.
-
Naja, fest steht zumindest, dass kein Spieleprogrammierer jemals Vektoren oder Matrizen mit variabler Komponentenzahl braucht (außer vielleicht ein paar ganz Esoterische
). Man braucht vll. 2D- und 3D-Vektoren bzw. 2x2-, 3x3- und 4x4-Matrizen in einer Anwendung, aber keine beliebigen Vektoren oder Matrizen. Deren Einsatzbereich liegt eher bei der linearen Algebra, wo es um das Lösen von Gleichungssystemen geht.