Heap versus Stack

volkard

Hesp schrieb:

wieviel schneller ist es ein Object auf dem Stack zu erzeugen als auf dem Heap?

83-mal so schnell.

falls es bei dir 82-mal so schnell oder 84-mal so schnell ist, ist dein rechner kaputt. dann mußt du ihn schnell einpacken und an mich schicken. falls er noch zu retten ist, repariere ich ihn und schicke ihn zurück.

ps: unter umständen könnten unterschiede auch hervorgerufen werden duch unterschiedliche prozessoren, andere cache-größen, unterschiedlich schnelles ram und andere implementierung. ist es ein find-first-allokator mit doppelt verketten listen (lahm aber fast ohne verschwendung), ist es ein buddy-allokator (bis zu 50% verschwendung aber sauschnell), hat er nen small-objekt-allokator davor (der allein bringt mehr als faktor 10 für kleine objekte), haste ne garbage collection dahinter (in c++ unüblich, aber erlaubt, kann speed bringen) oder ne pool-freigabe (bringt definitiv speed). welche threading-policy haste, dann synchronisation ist durchaus das ärgste problem am gesamten speichermanagement.

FireFlow

Buh Klugscheissmodus:

Es gibt kein Heap in Standard-C++, es gibt nur Free Store

Gruß

7H3 N4C3R

FireFlow schrieb:

Buh Klugscheissmodus:

Es gibt kein Heap in Standard-C++, es gibt nur Free Store

Gruß

Standard 25.3.6 : Heap Operations :p

(auch wenn da was anderes gemeint ist )

FireFlow schrieb:

Buh Klugscheissmodus:

Es gibt kein Heap in Standard-C++, es gibt nur Free Store

Gruß

Doch gibt auch in Standard-C++ nen Heap, du darfst ja auch in iso-c++ malloc verwenden :p

groovemaster

volkard schrieb:

falls er noch zu retten ist, repariere ich ihn und schicke ihn zurück.

Hehe, erzähl mal noch einen. Du würdest den Rechner doch nie zurückschicken und behaupten, er sei schrottreif. :p

joomoo

Hesp schrieb:

Beim Stack muss ja kein Speicher alloziiert werden...

Nein?

HumeSikkins

joomoo schrieb:

Hesp schrieb:

Beim Stack muss ja kein Speicher alloziiert werden...

Nein?

Nein! Zumindest nicht in dem Sinne wie bei einem Heap. Bei einer Stack-Allokation wird lediglich der Stack-Pointer um einen festern Wert verschoben (durch eine simple Addition). Im Gegensatz zu einer Heap-Allokation ist eine Stack-Allokation immer eine constant-time-operation.

Eine Heap-Allokation kann doch je nach Implementierung auch in (amortisiert) konstanter Zeit geschehen. Bei "gescheiten" GC-Heaps ist das sogar der Regelfall, dass auch nur ein Pointer dafür erhöht wird.
In jedem Fall sehe ich den Punkt, warum das Allokieren auf dem Stack nicht so heißen darf, nicht.

groovemaster schrieb:

volkard schrieb:

falls er noch zu retten ist, repariere ich ihn und schicke ihn zurück.

Hehe, erzähl mal noch einen. Du würdest den Rechner doch nie zurückschicken und behaupten, er sei schrottreif. :p

T_T du hast im die pointe seines witzes versaut

wär denn mal ne ernste antwort möglich, oder gibs keine
gibts da tuningmöglichkeiten zb bei simulationen (populationszyklen, klimamodelle..)? mehr speed wär schon noch interessant
ich kenn nur trading policy
und pool freigabe ab dem ersten heissen frühlingstag

und bitte nicht gleich heaperventilieren..
aber wenn ich ne ganze menge objekte verschiedener klassen dynamisch erzeug, alle paar zyklen wieder n paar lösch, und der zyklus so etwa 100ms oder weniger dauert, komm ich irgendwann an grenzen mit der effizienz oder?
bin mir über den zu verwendenden container/objektmanager auch noch nicht ganz sicher.. ??
folgendes:

list<list<earth_object*>*> *master_list;
list<earth_object*> *nutrient_list;
nutrient* Sugar;   // nutrient erbt von earth_object
...
master_list->add( nutrient_list = new list<earth_object*>() );
nutrient_list->add( NutSugar = new nutrient( "Sugar", clRed, 0, 1 ) );
...
nutrient_list->paint( paint_area_1 );

ist doch nicht wirklich schön oder?
(projekt noch im entwurf, daher noch nicht viel source)