Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Stack vs. Heap

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
28.04.2006, 11:56 Uhr
Drager



Hallo,

ich bin grad am überlegen ob ich mein objekt auf den stack oder auf den heap ablegen sollte... bei dem objekt handelt es sich um einen clipping-cube für beliebige objekte in der szene (8 ecken a 3 floats a 4 byte = 96 byte, *2 , da ich nen buffer hab der den grundcube speichert, also 192 byte pro objekt)

so wenn ich jetzt überlege , dass ich vielleicht ca. 10 000 objekte in der szene habe, und jedes von denen in durchschnitt 3 cubes besitzt, also ca 30 000 cubes, dann wären das 5,76 mbyte, ich könnte diese objekte auch nicht dynamisch erzeugen, aber einige compiler mögen so grosse stacks nicht (auch betriebssysteme??) andererseits ist dynamisch ja immer etwas langsamer.... auch lösche und lade ich ja dauernt neue objekte, d.h. es muss oft speicher reserviert und freigegeben werden...

darum meine frage: was würdet ihr tun? oder macht das kaum einen unterschied?

p.s. ich kann mir leicht vorstellen, dass das später mal auf über 10 mb anwächst...


grüsse

Drager
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
28.04.2006, 13:02 Uhr
ao

(Operator)



Zitat von Drager:
... 96 byte ... 10 000 objekte ... 30 000 cubes ... später mal auf über 10 mb

Das einzelne Objekt ist also eher klein, aber du brauchst riesige Mengen von Objekten. Vielleicht ist eine Art "Objekt-Pool" ein Lösungsansatz:

Du verwaltest ein Array (in C++ natürlich vector<> oder was andere Geeignetes), reservierst beim Laden der Szene gleich Platz für 10.000 Cubes oder so und gibst diese einen nach dem anderen an die Spielroutinen heraus. Das müsste ziemlich schnell gehen, weil du nur Referenzen auf bereits existierende Objekte verteilen musst.

Natürlich musst du dir merken, welche Cubes benutzt werden und welche nicht, aber das müsste gut automatisierbar sein, indem die Objekte, die die Cubes anfordern und erhalten, gezwungen werden, diese in ihren Destruktoren wieder loszulassen -> Das schreit nach Basisklasse mit virtuellem Destruktor.

Wenn du merkst, dass dir die Cubes ausgehen, musst du rechtzeitig beim Betriebssystem neue anfordern.

Übrigens, ist mit "cube" gemeint, dass die Objekte tatsächlich würfelförmig sind (90 Grad Innenwinkel, Kanten gleich lang)? Dann brauchst du nicht alle 8 Ecken zu speichern, mit vieren ist die Beschreibung schon eindeutig.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
28.04.2006, 13:47 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat von ao:

Du verwaltest ein Array (in C++ natürlich vector<> oder was andere Geeignetes), reservierst beim Laden der Szene gleich Platz für 10.000 Cubes oder so und gibst diese einen nach dem anderen an die Spielroutinen heraus. Das müsste ziemlich schnell gehen, weil du nur Referenzen auf bereits existierende Objekte verteilen musst.


Hier sollte man Vorsicht walten lassen: STL Container zeichnen sich durch Blindes kopieren aus. Dh wenn Du einen Cube in einen Vector tust, dann wird nicht etwa der Cube, sonder ein Clone davon in den vector getan. Abhilfe schaffen hier vectoren auf (Smart)Pointer basis, aber dann sollte man noch den Overhead durch die Smartpointer mit einrechnen. Möglicherweise ist man also mit einem STL Container nicht ganz so gut bedient.


Zitat von ao:

Natürlich musst du dir merken, welche Cubes benutzt werden und welche nicht, aber das müsste gut automatisierbar sein, indem die Objekte, die die Cubes anfordern und erhalten, gezwungen werden, diese in ihren Destruktoren wieder loszulassen -> Das schreit nach Basisklasse mit virtuellem Destruktor.


Wer sich Gedanken macht, daß das dynamische Holen von Speicher vielleicht teuer sei, der müsste theoretisch auch besorgt sein, daß virtuelle Methoden auch geringfüfgig teurer sind als die mit früher Bindung.

Ich würde generell bei diesem programm erstmal schreiben und mich erst zum Schluß um diese Optimierungsfragen kümmern.


Zitat:

Übrigens, ist mit "cube" gemeint, dass die Objekte tatsächlich würfelförmig sind (90 Grad Innenwinkel, Kanten gleich lang)? Dann brauchst du nicht alle 8 Ecken zu speichern, mit vieren ist die Beschreibung schon eindeutig.


Gute Idee. Hier hätte ich aber prompt auf nur drei Ecken getippt.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
28.04.2006, 14:55 Uhr
ao

(Operator)



Zitat von virtual:
Hier sollte man Vorsicht walten lassen: STL Container zeichnen sich durch Blindes kopieren aus. Dh wenn Du einen Cube in einen Vector tust, dann wird nicht etwa der Cube, sonder ein Clone davon in den vector getan.

Ich will die Cubes nicht hin- und herkopieren, die werden einmal im Pool angelegt und bleiben auch da. Wenn ein Client kommt und einen Cube will, kriegt er eine Referenz auf eins meiner Pool-Elemente und darf damit arbeiten. Und ich merke mir, dass ich dieses Element abgegeben habe.

Und damit ich sicher bin, dass ich den Cube am Ende wiederkriege, verlange ich, dass der Client von einer Basisklasse (z.B. "PoolClient") abgeleitet ist; diese Basisklasse hat alles, um ein Pool-Element anzufordern und um es - spätestens im Destruktor - wieder loszulassen.

Zitat:
Wer sich Gedanken macht, daß das dynamische Holen von Speicher vielleicht teuer sei, der müsste theoretisch auch besorgt sein, daß virtuelle Methoden auch geringfüfgig teurer sind als die mit früher Bindung.

Schon. Aber dafür kriege ich eine verbesserte Sicherheit gegen Speicherlecks, und das wär mir schon einen Preis wert.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
28.04.2006, 14:57 Uhr
Drager



huhu,

erstmal danke für die antworten, das programm ist an sich schon fertig und verwaltet die cubes auch selber, und die cubes sind rechteckig und nicht unbedingt an den axen ausgerichtet (weiss net reichen da auch weniger als 8 ecken?)

ich wollte eigendlich nur wissen, ob es von seiten des betriebssystems (linux / windows)
möglich ist einen stack der über 5-10 mb gross ist zu haben (bzw. wie gross dieser werden darf).. oder ob es da probleme gibt..
weil ich würde das schon gern statisch machen (ob jetzt schneller oder net, es ist einfach einfacher zu verwalten..)

grüsse

Drager

Dieser Post wurde am 28.04.2006 um 15:11 Uhr von Drager editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
28.04.2006, 15:30 Uhr
ao

(Operator)



Zitat von Drager:
die cubes sind rechteckig und nicht unbedingt an den axen ausgerichtet (weiss net reichen da auch weniger als 8 ecken?)

Ja, vier Ecken reichen. Die anderen vier ergeben sich durch vektorielle Addition der Kanten. Das gilt übrigens nicht nur für Würfel, sondern auch für Quader und für diese schiefen Körper, deren Seitenflächen Parallelogramme sind, Spat heißt so ein Ding, oder?

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
28.04.2006, 15:50 Uhr
virtual
Sexiest Bit alive
(Operator)


Geht es nicht auch mit drei Punkten?

1. Punkt ist die Mitte des Quaders
2. Punkt ist eine Ecke des Quaders
3. Punkt ist eine diagonal auf der gleichen Seite gegenüberliegende Ecke.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
28.04.2006, 16:39 Uhr
RHBaum



Bin nich so der Fachman von Speicherverwaltungen ...

Unter Linux soll der Stack angeblich das anziehen koennen, wass sein speichermanager freimachen kann ...
Da sollten auch paar MB gehen, vorrausgesetzt der speichermanager schafft es den platz zu raeumen / der platz ist eh da ...
Unter windows hat man eher festere grenzen ... weiss nich was die grenze da ist ...

Aber denk AO's vorschlag mit dem Pool ist da der gaengiste,verbreiteste und standard ... einmal anziehen (ein new ist nich zu teuer, und das kann man hinverschieben wo es nicht weh tut ) ....
und macht bei groesseren Bloecken auch kaum nen unterschied ...
ob BS roedelt weil die die Anforderungen des progs an Stack gewaltig sind und erst platz dafuer geschaffen werden muss, oder der erste Aufruf im prog kiloweise Memory am steuck allociert und der speichermanager da ins schwitzen kommt, ist fuer den user eigentlich gleich ....
Genau so gleich sind die sympthome wenn der Platz nimmer da ist ^^ zumindest unter windows ^^

Ciao ...
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
008
28.04.2006, 17:19 Uhr
stephanw
localhorst


Klar würden auch 3 Punkte reichen. Je weniger Punkte, umso mehr muss man rechnen. Da muss man sich irgendwann möglicherweise zwischen Laufzeit- oder Speicher-Effizienz entscheiden.
--
Reden ist Schweigen und Silber ist Gold.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
009
28.04.2006, 19:38 Uhr
ao

(Operator)



Zitat von virtual:
Geht es nicht auch mit drei Punkten?

1. Punkt ist die Mitte des Quaders
2. Punkt ist eine Ecke des Quaders
3. Punkt ist eine diagonal auf der gleichen Seite gegenüberliegende Ecke.

Nein, weil der Quader dann noch um 180° um die Mittelnormale dieser Seitenfläche rotieren kann.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: