diff --git a/src/lib/allocation-cluster.hpp b/src/lib/allocation-cluster.hpp index 360d779a5..330381c4c 100644 --- a/src/lib/allocation-cluster.hpp +++ b/src/lib/allocation-cluster.hpp @@ -44,19 +44,16 @@ #include "lib/error.hpp" #include "lib/nocopy.hpp" -#include "lib/sync-classlock.hpp" -#include "lib/scoped-holder.hpp" -#include "lib/scoped-holder-transfer.hpp" -#include -#include +#include ///////////////////OOO woot? +#include namespace lib { - /** + /** * A pile of objects sharing common allocation and lifecycle. * AllocationCluster owns a number of object families of various types. * Each of those contains a initially undetermined (but rather large) @@ -100,6 +97,10 @@ namespace lib { AllocationCluster* mother_; }; + /* maintaining the Allocation */ + void* storage_; + size_t remain_; + public: AllocationCluster (); ~AllocationCluster () noexcept; @@ -109,7 +110,7 @@ namespace lib { TY& create (ARGS&& ...args) { - return * new(allotMemory (sizeof(TY))) TY (std::forward (args)...); + return * new(allot()) TY (std::forward (args)...); } template @@ -141,16 +142,20 @@ namespace lib { * possibly claiming a new pool block. */ void* - allotMemory (size_t bytes) + allotMemory (size_t bytes, size_t alignment) { + void* loc = std::align(alignment, bytes, storage_, remain_); + if (loc) + return loc; UNIMPLEMENTED ("actual memory management"); + ///////////////////////////////////////////////////////////OOO claim next macro block } template X* allot (size_t cnt =1) { - return static_cast (allotMemory (cnt * sizeof(X))); + return static_cast (allotMemory (cnt * sizeof(X), alignof(X))); } }; diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 364db1b8f..01cf0c594 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -80694,8 +80694,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

- - + @@ -80708,8 +80707,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...

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

- - + @@ -81064,8 +81061,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
oder man bekommt eine implizite Runtime

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

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

- - + @@ -81111,8 +81105,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

- - + @@ -81144,8 +81137,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
⟹ bläht die Storage um 30% auf

- - + @@ -81168,8 +81160,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + @@ -81182,8 +81173,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.

- - + @@ -81203,8 +81193,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

- - + @@ -81222,8 +81211,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.

- - + @@ -81242,8 +81230,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

- - + @@ -81269,8 +81256,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + @@ -81282,8 +81268,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

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

- - + @@ -81312,8 +81296,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.

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

- - + @@ -81341,8 +81323,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.

- - + @@ -81354,8 +81335,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
die Bedeutung ist geringer geworden

- - + @@ -81365,8 +81345,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

- - + @@ -81382,8 +81361,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.

- - + @@ -81703,8 +81681,60 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -81730,8 +81760,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
Der Beschluß zur Lösung sieht vor, diese Belange markierbar zu machen, um dann später differenziert handeln zu können.

- - + @@ -81747,8 +81776,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)

- - + @@ -81962,8 +81990,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

- - + @@ -81975,8 +82002,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.

- - + @@ -81988,8 +82014,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

- - + @@ -82003,8 +82028,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.

- - + @@ -82016,8 +82040,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
in der Regel sind es cold pages

- - + @@ -82027,8 +82050,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...

- - + @@ -82040,8 +82062,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

- - + @@ -82053,8 +82074,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.

- - + @@ -82071,8 +82091,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
Ich handle hier nur auf Basis eines Bauchgefühls, und alle Erfahrung zeigt, daß man dabei meist die Gewichte falsch setzt.

- - + @@ -82094,8 +82113,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

- - +