diff --git a/src/lib/allocation-cluster.cpp b/src/lib/allocation-cluster.cpp index 5bce5860f..6bb9a56e2 100644 --- a/src/lib/allocation-cluster.cpp +++ b/src/lib/allocation-cluster.cpp @@ -33,8 +33,6 @@ #include "lib/linked-elements.hpp" #include "lib/util.hpp" -#include -#include using util::isnil; @@ -87,6 +85,7 @@ namespace lib { using Destructors = lib::LinkedElements; struct Extent + : util::NonCopyable { Extent* next; Destructors dtors; @@ -116,13 +115,21 @@ namespace lib { prependNextBlock(); } + void + discardAll() + { + closeCurrentBlock(); + view_.extents.clear(); + } + private: void closeCurrentBlock() { ASSERT (view_.storage.pos); // relocate the pos-pointer to the start of the block - view_.storage.pos += view_.storage.rest - EXTENT_SIZ; + view_.storage.pos = static_cast(view_.storage.pos) + + view_.storage.rest - EXTENT_SIZ; view_.storage.rest = 0; } @@ -154,9 +161,8 @@ namespace lib { AllocationCluster::~AllocationCluster() noexcept try { - TRACE (memory, "shutting down AllocationCluster"); - + StorageManager::access(*this).discardAll(); } ERROR_LOG_AND_IGNORE (progress, "discarding AllocationCluster") @@ -185,6 +191,17 @@ namespace lib { UNIMPLEMENTED ("size limits"); ///////////////////////////OOO enforce maximum size limits } + size_t + AllocationCluster::numExtents() const + { + UNIMPLEMENTED ("Allocation management"); + } + + size_t + AllocationCluster::numBytes() const + { + UNIMPLEMENTED ("Allocation management"); + } } // namespace lib diff --git a/src/lib/allocation-cluster.hpp b/src/lib/allocation-cluster.hpp index 627f598b2..2eda39b41 100644 --- a/src/lib/allocation-cluster.hpp +++ b/src/lib/allocation-cluster.hpp @@ -45,12 +45,12 @@ #include "lib/error.hpp" #include "lib/nocopy.hpp" -#include ///////////////////OOO woot? #include namespace lib { + namespace test { class AllocationCluster_test; } // declared friend for low-level-checks /** @@ -104,6 +104,18 @@ namespace lib { { void* pos{nullptr}; size_t rest{0}; + + void* + allot (size_t bytes, size_t alignment) + { + void* loc = std::align (alignment, bytes, pos, rest); + if (loc) + { // requested allocation indeed fits in space + pos = static_cast(pos) + bytes; + rest -= bytes; + } + return loc; + } }; Storage storage_; @@ -129,17 +141,8 @@ namespace lib { /* === diagnostics === */ - size_t - numExtents() const - { - UNIMPLEMENTED ("Allocation management"); - } - - size_t - numBytes() const - { - UNIMPLEMENTED ("Allocation management"); - } + size_t numExtents() const; + size_t numBytes() const; private: @@ -151,12 +154,10 @@ namespace lib { allotMemory (size_t bytes, size_t alignment) { ENSURE (_is_within_limits (bytes, alignment)); - void* loc = std::align (alignment, bytes, storage_.pos, storage_.rest); - if (loc) - return loc; + void* loc = storage_.allot(bytes, alignment); + if (loc) return loc; expandStorage (bytes); return allotMemory (bytes, alignment); - ///////////////////////////////////////////////////////////OOO claim next macro block } template @@ -168,6 +169,8 @@ namespace lib { void expandStorage (size_t); bool _is_within_limits (size_t,size_t); + + friend class test::AllocationCluster_test; }; diff --git a/tests/library/allocation-cluster-test.cpp b/tests/library/allocation-cluster-test.cpp index 657f7654c..9f60ec030 100644 --- a/tests/library/allocation-cluster-test.cpp +++ b/tests/library/allocation-cluster-test.cpp @@ -49,6 +49,7 @@ using std::numeric_limits; using std::function; using std::vector; using std::array; +using std::byte; @@ -61,6 +62,8 @@ namespace test { const uint NUM_TYPES = 20; const uint NUM_OBJECTS = 500; + const size_t BLOCKSIZ = 256; ///< @warning actually defined in allocation-cluster.cpp + long checksum = 0; // validate proper pairing of ctor/dtor calls template @@ -141,8 +144,10 @@ namespace test { virtual void run (Arg) { - simpleUsage(); - checkLifecycle(); +// simpleUsage(); +// checkLifecycle(); + verifyInternals(); + use_as_Allocator(); } @@ -163,8 +168,7 @@ namespace test { CHECK (123==ref2.getID()); CHECK (45 ==ref3.getID()); - CHECK (1 == clu.numExtents()); - CHECK (66+77+77 == clu.numBytes()); + CHECK (1 == clu.numExtents()); // now use objects and just let them go; } @@ -182,6 +186,50 @@ namespace test { } CHECK (0==checksum); } + + + /** @test cover some tricky aspects of the low-level allocator + * @remark due to the expected leverage of AllocationCluster, + * an optimised low-level approach was taken on various aspects of storage management; + * the additional metadata overhead is a power of two, exploiting contextual knowledge + * about layout; moreover, a special usage-mode allows to skip invocation of destructors. + * To document these machinations, change to internal data is explicitly verified here. + * @todo WIP 5/24 🔁 define ⟶ implement + */ + void + verifyInternals() + { + CHECK (0==checksum); + { + AllocationCluster clu; + CHECK (0 == clu.numExtents()); + CHECK (0 == clu.numBytes()); + + auto i1 = clu.create (1 + uint16_t(rand())); + CHECK (i1 > 0); + CHECK (1 == clu.numExtents()); +SHOW_EXPR(clu.numBytes()) +SHOW_EXPR(clu.storage_.rest); +SHOW_EXPR(clu.storage_.pos); + byte* blk = static_cast(clu.storage_.pos); +SHOW_EXPR(blk); + CHECK (blk); + blk += clu.storage_.rest - BLOCKSIZ; +SHOW_EXPR(blk); +SHOW_EXPR(blk[0]); + } + CHECK (0==checksum); + } + + + /** @test TODO demonstrate use as Standard-Allocator + * @todo WIP 5/24 🔁 define ⟶ implement + */ + void + use_as_Allocator() + { + UNIMPLEMENTED ("Clusterfuck"); + } }; LAUNCHER (AllocationCluster_test, "unit common"); diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 6e2ddef12..2c03b54fb 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -80686,9 +80686,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

An der Stelle habe ich nicht weiter analysiert, sondern einfach Heap-Allokationen gemacht; der Grund seinerzeit war, daß Christian den »Mempool« überall einführen wollte — ein Ansatz, den ich grundsätzlich unterstützte, wenngleich auch seine Implementierung zu einfach war, und ich damit diesen use-Case nicht sauber realisieren konnte. Damit unterblieben aber weitere Überlegungen zum Allocation-Trend @@ -80699,9 +80697,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

damals hatte ich als Vorbild den small-objects pool allocator von Alexandrescu im Kopf; deshalb habe ich auch »Familien« von Objekten vorgesehen — ohne jedoch zu klären, ob und wie sich daraus ein Amortisierungs-Effekt ergibt. Nach gründlicherer Überlegung erscheint mir das als ein Widerspruch im Konzept, denn diese small-objects-Pools laufen ja auf ein Tiling mit fortlaufend stattfindedenden Allokationen hinaus; das ist exakt das Gegenteil von dem, was mir hier vorschwebt. Damit würden die Einzelpools nur Administrations-Overhead verursachen, der seine Vorteile überhaupt nicht ausspielen kann; stattdessen sollte besser in Betracht gezogen werden, alles heterogen, so wie es kommt, in größere Blöcke zu packen. Das Tiling würde damit auf einem größeren Level stattfinden, und wäre in den Basis-Allocator verlagert... @@ -80989,9 +80985,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

⟹ Konsequenz: zusätzlicher Template-Parameter für das Spacing @@ -81053,9 +81047,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

oder man bekommt eine implizite Runtime @@ -81075,9 +81067,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

wenn die Daten „woanders“ liegen @@ -81087,9 +81077,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

⟹ das Allocator-Problem überträgt sich komplett  auf den Container selber @@ -81097,9 +81085,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

warum? weil man dann zwingend im Container selber einen »Slot« mit einem Functor oder Allocator-Pointer rumschleppt — oder doch wieder einen zusätzlichen Instanz-Typ-Tag @@ -81118,9 +81104,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Sorge: @@ -81141,9 +81125,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Da der Heap-Allokator inzwischen ziemlich performant ist, könnte man damit durchkommen... @@ -81165,9 +81147,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...man verwendet nur speziell im produktiven Einsatz im Node-Graph  einen besonderen Allocator, der zwar den Destruktor aufruf, aber den Speicher nicht freigibt; alloziert wird immer in einen kompakten Block hinein, der dann auf der Basis der Prozeß-Kenntnis als Ganzes verworfen und neu verwendet wird. @@ -81185,9 +81165,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...weil std::vector zwar bereits alles bietet, aber eingebettet in sehr komplexen Code — im Besonderen dürfte es schwierig werden, das Thema on-demand-growth vs non-copyable zu umschiffen @@ -81203,9 +81181,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...das heißt, ich gehe mal davon aus, daß ich mit einer einzigen, dedizierten Implementierung erst mal den aktuellen Bedarf decken kann; daraus könnte allerdings später immer noch ein Concept gemacht werden, welches dann alternativ auch durch ScopedCollection oder durch eine embedded-storage-Lösung erfüllt werden kann. @@ -81222,9 +81198,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

heterogene Allokation in eine Sequenz größerer Blöcke; keinerlei de-Allokation und kein Locking @@ -81234,9 +81208,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...sie ist ja fertig und getestet, und wartet seit Jahren auf ihren Einsatz; allerdings wäre ein solches Vorgehen erklärungsbedürftig @@ -81260,9 +81232,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...wenn man schon die bestehenden Implementierung nutzt (wohl wissend, daß ihre inhärenten Probleme erst mal nicht relevant sind), dann kann man genausogut ganz auf blöd sich auf den KISS-Standpunkt stellen und einfach Heap-Allokationen machen, denn die sind heutzutage verdammt effizient geworden @@ -81272,9 +81242,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...und alles das läuft auf weitere technische Schulden hinaus @@ -81288,9 +81256,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...die allesamt mit dem Model + Player zu tun haben; einzige externe Verkoppelung ist der LinkedElements_test, und auch dieser stellt explizit einen Vorgriff auf die Verwendung im low-level-Model dar. @@ -81300,9 +81266,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...da der davon abhängende Code effektiv nur compilierbar ist, aber nicht lauffähig @@ -81315,9 +81279,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

let it crash — wenn tatsächlich eine Exception fliegt, ist es ziemlich wahrscheinlich, daß der ganze Cluster sowiso weggeworfen wird; wenn nicht, dann akzeptieren wir einfach toten Speicher. @@ -81327,9 +81289,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

die Bedeutung ist geringer geworden @@ -81337,9 +81297,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

seinerzeit habe ich im AllocationCluster etwas gesehen, daß pervasiv überall im Code verwendet wird, analog zum Mempool. Inzwischen stehe ich auf dem Standpunkt, daß für die meisten Allokationen der Standard-Heap-Allokator sowiso gut genug ist (oder man nutzt ohnehin den Stack oder eine statische Variable); spezielle Allokatoren sind nach meinem heutigen Verständnis nur noch sinnvoll, wenn sie extrem spezifisch sind @@ -81353,9 +81311,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...oder zumindest könnte man ein limitiertes Teil-Konzept umsetzen; mir fällt auf, daß diverse Methoden im Standard-Allocator inzwischen durch Traits ersetzt wurden. @@ -81699,9 +81655,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

alignof()-Operator und die Hilfsfunktion std::align() @@ -81728,6 +81682,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + @@ -81742,8 +81699,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + @@ -81751,9 +81708,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

auch: eine gradzahlige Anzahl an Overhead-Slots @@ -81764,9 +81719,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...durch diesen Trick sparen wir uns einen zusätzlichen Pointer auf den aktuellen Block: da std::allign(pos,rest) den pos-Zeiger stets kohärent zusammen mit dem rest-cnt manipuliert, können wir stets aus beiden zusammen wieder zum Anfang des Blocks zurückfinden. @@ -81791,9 +81744,93 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + + + + + + + + + + + + + + + + + +

+ wie man's auch dreht und wendet: irgendwo muß die Typ-Information explizit untergrebracht werden, da wir sie vom Allocation-Cluster selber entfernt haben (dieser ist nun generisch und kann einen beliebigen Mix von Objekten/Typen allozieren). Das einzige, was man machen könnte, wäre diese Info komprimiert abzuspeichern.... +

+ + + + + + + + + + + + +

+ ...da man sich diesen Code ohnehin nur anschaut, wenn man muß, ist nichts mehr gewonnen, weitere Details nochmal durch eine Indirektion zu verbergen +

+ + + + + + + + + + + +

+ ...nämlich die Speicheradresse der Instanz +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -81802,9 +81839,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

In diesem Konflikt stehen zwei gleichermaßen bedeutsame Belange gegeneinander, ohne einen klaren Ansatz zur Entscheidung @@ -81829,9 +81864,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...somit kann auf Basis der einzelnen, konkreten Datenstruktur entschieden (und später auch korrigiert) werden, ob ein expliziter clean-up-Aufruf notwendig ist; für die einzelne Datenstruktur dürfte das lokal jeweils klar entscheidbar sein, und ich erwarte, daß durch die Anbindung an den Allocation-Cluster diese Entscheidungsmöglichkeit auch langfristig klar dokumentiert ist — und zwar sollte das von üblichen C++ Praktiken abweichende Verhalten auch als der Spezialfall dargestellt sein (wenngleich auch erwartet wird, daß die meisten Datenstrukturen von diesem Spezialfall gebrauch machen) @@ -81860,6 +81893,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + @@ -82043,9 +82083,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Kurzfristig erscheint das als eine naheliegende Optimierung, die einem praktisch »in den Schoß fällt« (die Implementierung wird dadurch sogar drastisch einfacher). Aber längerfristig befürchte ich eine heimtücksiche Gefahr, denn die hier genommene Abkürzung kann leicht übersehen werden, da sie den üblichen Gepflogenheiten zuwiderläuft. Im Lauf der Zeit können sich so Speicher- und Ressourcen-Lecks einschleichen, die dann nur mit erheblichem und fokussiertem Aufwand aufzuräumen sind @@ -82055,9 +82093,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Es handelt sich um eines der markanten Eigenschaften der Sprache C++ : Kontrolle und Determinismus bis ins kleinste Detail — und das prägt den alltäglichen Stil der Arbeit; weithin kann man sich auf Abstraktionen verlassen, weil diese sich wiederum auf Abstraktionen verlassen können; wenn alles genau und zuverlässig ist, dann werden auch weitreichende Aktionen planbar und handhabbar. @@ -82067,9 +82103,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Hier geht es um das gesamte low-level-Model, sowie möglicherweise Teile des Build-Prozesses und des Regelwerks, die daran angeknüpft sein könnten — und das bedeutet, mit einer (wie es zunächst scheint) sehr lokalen und tief verborgenen Optimierung könnte der Grund-Kontrakt in einem erheblichen Teil der Applikation geändert werden @@ -82081,9 +82115,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Der Aufwand, der allein für das Aufrufen der aller Destruktoren getrieben werden muß, ist nicht unerheblich, denn für jeden Typ muß eine Closure im Datensegment erzeugt werden und für jede einzelne Allokation muß diese per Funktionszeiger aufrufbar sein; außerdem muß die gesamte Allokation navigierbar gemacht werden — also zwei »Slots« zusätzlich für jede einzelne Allokation. Das ist sehr viel für eine Datenstruktur, die aus vielen kleinen und sehr flexiblen Descriptor-Elementen bestehen wird; die meisten Nodes haben erwartungsgemäß nur einen Eingang und einen Ausgang, was bedeutet, daß für jeweils nur eine einzige ID (ein »Slot«) zusätzlich ein Container (2 »Slot«) und dann noch 4 »Slot« Allokations-Overhead notwendig sind. @@ -82093,9 +82125,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

in der Regel sind es cold pages @@ -82103,9 +82133,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Aus Performance-Sicht besonders fatal ist, daß zum Zeitpunkt der Bulk-de-Allokation mit hoher Wahrscheinlichkeit alle betroffenen memory pages bereits »cold« sind, d.h. aus dem Cache herausgefallen; wir müssen also eine Menge von Speicherseiten über den Bus ziehen, bloß um sie zu navigieren und dann... @@ -82115,9 +82143,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...in den allermeisten Fällen nämlich exakt gar nichts  zu tun. Dies unter der Annahme, daß die Struktur größtenteils selbst-referentiell ist; zwar werden dadurch reihenweise verkettete Destruktor-Aufrufe stattfinden, welche aber alle letztlich beim Allocator enden, welcher dann (ganz bewußt) nichts tut, weil der gesamte Speicherblock anschließend ohnehin verworfen wird. Da es sich jedoch um dynamisch aufgebaute Datenstrukturen handelt, kann der Optimizer diesen Leerlauf nicht erkennen und beseitigen @@ -82127,9 +82153,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Es steht zu befürchten, daß während der normalen Edit-Tätigkeit alle par 1/10-sec ein Builder-Lauf getriggert wird — und ich schätze, daß ein erheblicher Anteil der tatsächlichen Laufzeit in das Konstruieren der Datenstruktur geht, denn der zugrundeliegende trade-off ist ja grade  space-for-time. Wenngleich auch der Neubau ebenfalls schlecht für den Cache ist, so kann man doch zumindet in Teilen hoffen, daß die neu gebauten Strukturen zumindest bis zur ersten Berührung durch den Play-Prozeß im L3 bleiben. Für die alten Strukturen gilt das aber nicht, sie stellen rein nutzlosen Balast dar. @@ -82141,9 +82165,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

das ist »der Klassiker«. @@ -82166,9 +82188,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Angenommen, ich mache diese Optimierung jetzt nicht, bereite sie aber vor; später dann zeigt sich (mit guter Wahrscheinlichkeit) tatsächlich ein relevanter Overhead ⟹ dann ist der Druck zur Optimierung umso stärker, und man wird die vorbereitete Option »ziehen« und die weitreichenden Konsequenzen in Kauf nehmen, da die Behebung eines konkreten Problems immer alle strategischen und methodischen Erwägungen übersteuert. Das wäre der schlechtest mögliche Verlauf, denn zu eine so späten Zeitpunkt kann man kaum mehr etwas tun, um eine weitreichende Änderung der Konventionen abzufedern @@ -126497,9 +126517,7 @@ std::cout << tmpl.render({"what", "World"}) << s - - - +

viel Geplänkel cool-getue; tatsächlich hat er schon einen eigenständigen Gedanken, braucht aber sehr lange, ihn auszuformulieren; und zu den schwierigen praktischen Fragen mit STL-Containern sagt er gar nichts @@ -126511,9 +126529,7 @@ std::cout << tmpl.render({"what", "World"}) << s - - - +

dann skizziert er alle wesentlichen Standard-Allocator-Patterns als  composable allocators @@ -126533,9 +126549,7 @@ std::cout << tmpl.render({"what", "World"}) << s - - - +

Begründung: es ist sinnlos, weil das einzige, was man dabei machen kann, ist Fehler machen. Der Standard ist extrem genau und elaboriert für dieses Thema, und wenn man sich an wirklich alle Vorgaben hält, hat man praktisch keinen Spielraum mehr.... @@ -126545,9 +126559,7 @@ std::cout << tmpl.render({"what", "World"}) << s - - - +

...bei Bedarf kann man dort sogar einige optionale Methoden zusätzlich implementieren, z.B. construct (und das wird dann auch verwendet, anstatt der Standard-Implementierung in den Traits)