Laufzeitverhalten Heap zu Stack
-
kann man das nicht mit asm machen?
dynamische arrays aufn stack?
-
Das Problem ist, dass die Größe eines Stackframes dann nicht mehr konstant ist. Wenn sich der C++ Compiler darauf verlässt, bringt das vielleicht Ärger.
-
Natürlich würde es mit ASM gehen, aber wie Optimizer schon sagte kann das Probleme mit dem Compiler geben, wobei man da sicher auch irgendwo was einstellen kann.
-
mit asm geht das, wenn der compiler probleme damit hat, dann ist es compiler schuld, denn wenn man inline assembler ausführen kann, muss der compiler an der stelle davon ausgehen, dass jedes register vom 'user' verändert wird. für das verhalten dann ist natürlich der user zuständig, denn er muss bei c++ wissen was er macht.
das problem was jedoch auftauchen könnte, wäre dass das array nicht die höchste variable auf dem stack ist und man deswegen speicher überschreibt.ich empfehle an dieser stelle, sich ne kleine klasse zu schreiben die speicher wie einen stack verwaltet, dann legt man sich dort arrays beliebiger größe zur laufzeit an, dann ist das laufzeitverhalten wie beim normalen stack, man hat die größenlimitierung wie beim normalen stack, kein problem damit den speicher mit anderen variablen zu überschreiben und kein assemblergefricke.
rapso->greets();
-
Optimizer schrieb:
Wo ist denn außerdem dein Problem, das Array auf dem Heap anzulegen, das ist doch eine schöne Lösung.
Es geht mir halt um die Laufzeit. Meine Daten die ich in das Array schmeißen muß kommen so fix rein, daß jede µs zählt die ich sparen kann. Nun kann ich aber die Anzahl der Daten die ins Array gespeichert werden müssen nicht zur Compilierzeit abschätzen.
-
Wie Bashar so sagte, auf dem Heap solltest du mit der selben Geschwindigkeit zugreifen können müssen. Das Anlegen wird vermutlich etwas länger dauern, aber das ist einmalig. Ich kann mir nicht vorstellen, dass die paar Nanosekunden groß was rausreißen.
Und du hast so wie es aussieht auch noch kein konkretes Problem, nachdem du es ja noch überhaupt nicht implementiert hast. Premature optimization is the root of all evil. Das hier ist ein wunderschönes Beispiel. Anstatt komfortabel std::vector zu benutzen, wird hier auf Verdacht mal schnell was mit Assembler gehackt um dynamische Arrays auf dem Stack zu haben.
Davon rate ich ab.
-
Lächerlich und traurig als angebliche C++-Coder was von realloc oder gar ASM zu reden.
Es gibt doch (wie von leider nur wenigen gesagt) das std::vector. Alles andere ist SCHWACHSINN!
-
std::vector verwenden und wenn der Profiler dir dann zeigt, dass vector zu langsam allokiert einfach nen eigenen Allokator schreiben -> erstmal einen fastAllocator, der großzügiger mit dem Speicher umgeht um reallokationen zu vermeiden/verringern. Wenn das auch nicht klappt non-standard Wege suchen, zB per alloca() auf dem Stack reservieren oder andere Allokatorstrategieren ausprobieren.
Das schöne: du hast erstmal ne Lösung mit std::vector die funktioniert und vielleicht sogar schnell genug ist. Wenn es zu langsam ist, kannst du (ohne den Code zu ändern) einfach andere Allocatoren testen.
So macht optimierung mehr sinn.
Premature optimiziation ist zwar the root of all evil, aber dennoch sollte man Optimierungen in der Designphase beachten (und versuchen sich diese nicht durch Designentscheidungen zu verbauen - natürlich heisst das jetzt nicht, dass man gleich alle Optimierungen "reindesignen" soll - aber im Hinterkopf behalten ist ganz gut) -> wie du siehst ist std::vector somit eine gute Entscheidung.
-
man kann ja bei std::vector wunderbar mit std::vector::reserve vorher genug Speicher allozieren und so die Allozierung aus Zeitkritischen Bereichen fernhalten.
-
Artchi schrieb:
Lächerlich und traurig als angebliche C++-Coder was von realloc oder gar ASM zu reden.
Es gibt doch (wie von leider nur wenigen gesagt) das std::vector. Alles andere ist SCHWACHSINN!ähm ich war einer der ersten der den vector vorgeschlagen hat.
und als C++ Coder sollte man nicht fergessen das es noch ASM und realloc gibt ( IMHO )