spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Stichwort vector

Es kommt ein wenig darauf an, wie du "sehr groß" definierst. Der Stack ist unter Windows per Default nur 1 MB groß. Brauchst du mehr Platz, musst du das Array auf dem Heap erzeugen. Also einfach per new. Das sollte für einige MB problemlos reichen. Irgendwann stößt du dabei (zumindest bei 32 Bit) auf das Problem, dass ein zusammenhängender Adressbereich gefunden werden muss. Dann könnte man die Speicherallokationen splitten, aber ich vermute so weit reicht dein Problem nicht.

Zusammenhängender Adressbereich ist eigentlich kein Problem dank virtueller Speicherverwaltung. Adressen sind ohnehin alle virtuell und Speicher zusammengestückelt. Darum kümmert sich Windows dann schon.

Zitat von »BlueCobold«

Zusammenhängender Adressbereich ist eigentlich kein Problem dank virtueller Speicherverwaltung. Adressen sind ohnehin alle virtuell und Speicher zusammengestückelt. Darum kümmert sich Windows dann schon.

Virtuelle Speicherverwaltung sorgt nur dafür, dass der Speicher nicht zusammenhängend sein muss. Der Adressbereich muss weiterhin zusammenhängend sein. Und auch der virtuelle Adressraum ist mit reservierten Bereichen durchzogen und von Fragmentierung betroffen. Die Chance 1000 mal 1 MB zu bekommen ist da generell größer als 1 mal 1000 MB.

Rein prinzipiell kann man natürlich auch einfach von vornherein einen größeren Stack für sein Programm anfordern. Aber ich vermute mal, dass std::vector die bessere Lösung sein wird. Ohne zu wissen, worum es sich konkret handelt, kann man am Ende aber natürlich nur spekulieren...

Zitat von »Tobiking«

Zitat von »BlueCobold«

Zusammenhängender Adressbereich ist eigentlich kein Problem dank virtueller Speicherverwaltung. Adressen sind ohnehin alle virtuell und Speicher zusammengestückelt. Darum kümmert sich Windows dann schon.

Virtuelle Speicherverwaltung sorgt nur dafür, dass der Speicher nicht zusammenhängend sein muss. Der Adressbereich muss weiterhin zusammenhängend sein. Und auch der virtuelle Adressraum ist mit reservierten Bereichen durchzogen und von Fragmentierung betroffen. Die Chance 1000 mal 1 MB zu bekommen ist da generell größer als 1 mal 1000 MB.

Du spielst wohl auf externe Fragmentierung an? Damit hatte ich persönlich erst ein einziges Mal wirklich Probleme und das war in einer 32 Bit .NET Anwendung, die mit Arrays in der Größenordnung von hunderten MB hantiert hat und das war damals wohl mindestens zur Hälfte der Garbage Collection zu verdanken...

Zitat von »dot«

Du spielst wohl auf externe Fragmentierung an? Damit hatte ich persönlich erst ein einziges Mal wirklich Probleme und das war in einer 32 Bit .NET Anwendung die mit Arrays in der Größenordnung von GB hantiert hat und war wohl zur Hälfte der Garbage Collection zu verdanken...

Genau. Es macht sich wenn dann eh erst dann bemerkbar, wenn das Programm schon viel Speicher reserviert und wieder freigegeben hat. Aber zu verachten ist es nicht, besonders wenn man wirklich große Speicherbereiche haben möchte. Deswegen zumindest die Erwähnung. Im CPP Forum gabs da auch mal einen Thread zu, ich finde den aber gerade auf Anhieb nicht.

Hmm, ja gut, wenn der virtuelle Adressraum schon zerhackstückt ist, ist das natürlich ein Problem. Ich ging vom physischen Adressraum aus und dass er solche Arrays irgendwo in einer Initialisierung anlegt, wo dann der virtuelle Adressraum natürlich noch sehr jungfräulich ist.

Wenn der Threadersteller mit seinen Arrays auf dem Stack überhaupt eine Chance hat, dass sein Programm durchläuft, wird Adressraumfragmentierung wahrscheinlich eher nicht sein Problem werden - so riesig scheinen die Arrays ja auch nicht zu sein.