Pool
-
Hallo!
Für Objekte einer Klasse, deren Anzahl im Vorhinein unbekannt ist, soll ein Memory-Pool verwendet werden. Ich verwende dafür Boost. Der Wunsch ist aber, den Speicherbedarf der Software zu minimieren. Die Software speichert eine große Anzahl von Pointern auf die Objekte im Pool, und leider sind die auf 64bit-Rechnern 8 Bytes groß. Die Idee ist daher, als Handles nicht mehr Pointer, sondern unsigned Integers zu verwenden. Das Mapping von Integer auf Pointer wäre z.B. möglich, indem man einen vector<myObject*> mit den Pointern befüllt, die der Pool zurückliefert. Besser und performanter wäre aber ein Pool, der gleich einen Index statt eines Pointers zurückliefert und sich intern um die Adreßumsetzung kümmert. Gibt es sowas fertig?
Danke
-
d.h. du willst statt einem Pool mit Pointern zusätzlich eine map einführen die die Pointer auf integers mappt die man dann in den Pool speichert ... und dadurch Speicher sparen?
-
Einfach offsets Speichern.
Du merkst dir statt einen Zeiger auf foo einfach den Offset von foo zu bar.
Sprich: du hast eine Baseadresse (zB die startadresse des Pools und speicherst dann nur die offsets (du musst aber garantieren dass du keine negativen Offsets hast).
Prinzipiell klingt der Ansatz aber sehr fragwuerdig.
-
Shade Of Mine schrieb:
Einfach offsets Speichern.
Du merkst dir statt einen Zeiger auf foo einfach den Offset von foo zu bar.
Sprich: du hast eine Baseadresse (zB die startadresse des Pools und speicherst dann nur die offsets (du musst aber garantieren dass du keine negativen Offsets hast).
Prinzipiell klingt der Ansatz aber sehr fragwuerdig.
So dachte ich mir das, ja. Basisadresse plus ein Offsets, aus denen die echten Pointer errechnet werden. Bloß muß der zu reservierende Platz dynamisch wachsen können, was bedeutet, man hätte mehrere Speicherstücke von, sagen wir je 10000 Elementen, die der Pool verwaltet. Fragwürdig, in welcher Hinsicht? Ich weiß bloß nicht, ob das stark auf die Geschwindigkeit drücken würde.
-
wuzz schrieb:
Fragwürdig, in welcher Hinsicht?
Ein Pool bedeutet immer, dass du mehr Speicher brauchst als du aktiv nutzt. Der Pool muss verwaltet werden, das bedeutet Overhead. Der Pool muss Speicher allokieren, meistens mehr als du brauchst.
Und du willst Zeiger optimieren.
Das hoert sich falsch an. Anstatt die Zeiger von 64 auf 32 bit zu bringen waere es viel effektiver Speicher einzusparen.Wenn es nun wirklich an den Zeigern selber liegt (und da lohnt es sich meistens einfach die Datenstrukturen zu wechseln um die Zeiger zu eliminieren) dann wird es teuer von der Laufzeit her.
Ansonsten setzt man NACH dem Pool an. Der Pool liefert dir den Zeiger und du machst daraus ein X-Byte grosses Handle. Einen Smartpointer wenn man so will. Wenn alle Objekte gleich gross sind, muss man zB sich nur merken das wieviele Element man braucht.
Aber um ehrlich zu sein: das klingt alles furchtbar. Es ist soviel einfacher einfach die Objekte kleiner zu machen. Sind da vielleicht padding Bytes drinnen? Kann man da etwas gzipen? Kann man Zeiger/Handles vielleicht eliminieren. Kann man caches eliminieren. Sind die Datenstrukturen alle gut gewaehlt (idR kann man sich fuer Performance immer etwas Speicher sparen).
Es gibt soviele Ansaetze die ich alle zuerst verfolgen wuerde, bevor ich hier mit so komischen Smartpointern komme um den Speicherplatz zu reduzieren den ein einzelnen Zeiger braucht.