Library: draft a simpler STL complient allocation interface

After some analysis, it became clear that the existing code for
`AllocationCluster` (while in itself valid) will likely miss the point
for the expected usage in the low-level Model: most segments of the
model will be rather small, and thus there is not enough potential for
amortisation when using such a per-type and per-segment scheme;
a rather simplistic linear allocator will be sufficient.

On the other hand, with the current C++ standard it is easy to provide
a complient allocator implementation for STL containers, and thus the
interface should be retro-fitted accordingly.
This commit is contained in:
Fischlurch 2024-05-14 23:37:49 +02:00
parent db30da90ce
commit fd49c68096
2 changed files with 526 additions and 16 deletions

View file

@ -29,14 +29,9 @@
** as a whole. AllocationCluster implements memory management to
** support this usage pattern.
**
** @note this file is organised in a way which doesn't bind the
** client code to the memory manager implementation. Parts of the
** interface depending on the usage situation are implemented using
** templates, and thus need to be in the header. This way they can
** exploit the type information available in call context. This
** information is passed to generic implementation functions
** defined in allocation-cluster.cpp . In a similar vein, the
** AllocationCluster::MemoryManger is just forward declared.
** @warning in rework 5/2024 with the goal to simplify the logic,
** remove all thread safety and make the implementation
** usable as standard conformant allocator for STL.
**
** @see allocation-cluster-test.cpp
** @see builder::ToolFactory
@ -89,9 +84,22 @@ namespace lib {
* Is this issue worth the hassle? //////////////////////////////TICKET #169
*/
class AllocationCluster
: util::NonCopyable
: util::MoveOnly
{
template<typename X>
struct Allocator
{
using value_type = X;
[[nodiscard]] X* allocate (size_t n) { return mother_->allot<X>(n); }
void deallocate (X*, size_t) noexcept { /* rejoice */ }
Allocator(AllocationCluster* m) : mother_{m} { }
private:
AllocationCluster* mother_;
};
public:
AllocationCluster ();
~AllocationCluster () noexcept;
@ -101,8 +109,14 @@ namespace lib {
TY&
create (ARGS&& ...args)
{
TY* obj = new(allocation<TY>()) TY (std::forward<ARGS> (args)...);
return commit(obj);
return * new(allotMemory (sizeof(TY))) TY (std::forward<ARGS> (args)...);
}
template<typename X>
Allocator<X>
getAllocator()
{
return Allocator<X>{this};
}
@ -115,6 +129,24 @@ namespace lib {
private:
/**
* portion out the requested amount of memory,
* possibly claiming a new pool block.
*/
void*
allotMemory (size_t bytes)
{
UNIMPLEMENTED ("actual memory management");
}
template<typename X>
X*
allot (size_t cnt =1)
{
return static_cast<X*> (allotMemory (cnt * sizeof(X)));
}
/** initiate an allocation for the given type */
template<class TY>
void*

View file

@ -80681,6 +80681,37 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</html></richcontent>
</node>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1715625161792" ID="ID_748407633" MODIFIED="1715625275278" TEXT="Zweifel an bestehender Allocation-Cluster-Implemenierung">
<arrowlink COLOR="#fd2206" DESTINATION="ID_741455291" ENDARROW="Default" ENDINCLINATION="371;-21;" ID="Arrow_ID_148841438" STARTARROW="None" STARTINCLINATION="988;41;"/>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1715625311161" ID="ID_1762606958" MODIFIED="1715625461924" TEXT="der unterliegende Memory-Manager ist ungekl&#xe4;rt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
An der Stelle habe ich nicht weiter analysiert, sondern einfach Heap-Allokationen gemacht; der Grund seinerzeit war, da&#223; Christian den &#187;Mempool&#171; &#252;berall einf&#252;hren wollte &#8212; ein Ansatz, den ich grunds&#228;tzlich unterst&#252;tzte, wenngleich auch seine Implementierung zu einfach war, und ich damit diesen use-Case nicht sauber realisieren konnte. Damit unterblieben aber weitere &#220;berlegungen zum Allocation-Trend
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715625485709" ID="ID_323773842" MODIFIED="1715625503477" TEXT="zu viel Locking &#x2014; und m&#xf6;glicherweise an der falschen Stelle"/>
<node CREATED="1715625511889" HGAP="39" ID="ID_1920622182" MODIFIED="1715625840520" TEXT="Effizienz der Familien-Pools erscheint fragw&#xfc;rdig" VSHIFT="-29">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
damals hatte ich als Vorbild den <i>small-objects pool allocator </i>von Alexandrescu im Kopf; deshalb habe ich auch &#187;Familien&#171; von Objekten vorgesehen &#8212; ohne jedoch zu kl&#228;ren, ob und wie sich daraus ein Amortisierungs-Effekt ergibt. Nach gr&#252;ndlicherer &#220;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&#252;rden die Einzelpools nur Administrations-Overhead verursachen, der seine Vorteile &#252;berhaupt nicht ausspielen kann; stattdessen sollte besser in Betracht gezogen werden, alles heterogen, so wie es kommt, in gr&#246;&#223;ere Bl&#246;cke zu packen. Das Tiling w&#252;rde damit auf einem gr&#246;&#223;eren Level stattfinden, und w&#228;re in den Basis-Allocator verlagert...
</p>
</body>
</html>
</richcontent>
</node>
</node>
<node CREATED="1714870490954" ID="ID_433835630" MODIFIED="1714870505595" TEXT="Aufr&#xe4;umen">
<node CREATED="1714870511447" ID="ID_698798351" MODIFIED="1714870529856" TEXT="NodeGraphAttachment in ExitNode umwandeln"/>
<node CREATED="1714870530945" ID="ID_1030439043" MODIFIED="1714870546389" TEXT="bisherige skizzierte Rolle er ExitNode zur&#xfc;ckbauen"/>
@ -80987,6 +81018,29 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1715532615345" ID="ID_1951577105" MODIFIED="1715532623856" TEXT="keinerlei Container-Mutation"/>
</node>
</node>
<node CREATED="1715618121025" ID="ID_1771703333" MODIFIED="1715618125167" TEXT="usage-patterns">
<node CREATED="1715618155444" ID="ID_787577497" MODIFIED="1715618165722" TEXT="stets: bauen und dann unver&#xe4;ndert verwenden"/>
<node CREATED="1715618167076" ID="ID_407732173" MODIFIED="1715618185087" TEXT="Fall-1 : bekannte Zahl an Elementen wird schrittweise zusammengebaut"/>
<node CREATED="1715618185979" ID="ID_342860962" MODIFIED="1715618213307" TEXT="Fall-2 : Exploration liefert unbekannte Zahl an Elementen zur Konfiguration"/>
<node CREATED="1715618232322" ID="ID_682478842" MODIFIED="1715618242095" TEXT="Vergleich mit bestehenden Containern">
<node CREATED="1715618254530" ID="ID_1519146754" MODIFIED="1715618257565" TEXT="Vector">
<node CREATED="1715618258391" ID="ID_38531723" MODIFIED="1715618264773" TEXT="unterst&#xfc;tzt alle diese Pattern"/>
<node CREATED="1715618266011" ID="ID_203372325" MODIFIED="1715618270124" TEXT="ist dann aber mutable"/>
<node CREATED="1715618270856" ID="ID_1061712193" MODIFIED="1715618293534" TEXT="keine non-copyable elements"/>
</node>
<node CREATED="1715618298684" ID="ID_631212658" MODIFIED="1715618302184" TEXT="ScopedCollection">
<node CREATED="1715618303668" ID="ID_935483598" MODIFIED="1715618310854" TEXT="unterst&#xfc;tzt nur Fall-1"/>
<node CREATED="1715618311442" ID="ID_1623386726" MODIFIED="1715618330992" TEXT="unterst&#xfc;tzt ein weiteres Muster (RAII / Populator)"/>
<node CREATED="1715618379385" ID="ID_825375134" MODIFIED="1715618385077" TEXT="erlaubt non-copyable elements"/>
<node CREATED="1715618703910" ID="ID_753044820" MODIFIED="1715618720116" TEXT="(bisher) nur Heap-Allokation"/>
</node>
<node CREATED="1715618477780" ID="ID_1982987663" MODIFIED="1715618480152" TEXT="Deque">
<node CREATED="1715618481364" ID="ID_340038086" MODIFIED="1715618491385" TEXT="unterst&#xfc;tzt beide Pattern"/>
<node CREATED="1715618491930" ID="ID_332936386" MODIFIED="1715618499605" TEXT="erlaubt non-copyable elements"/>
<node CREATED="1715618597349" ID="ID_1869583826" MODIFIED="1715618611414" TEXT="aber keine continuous storage"/>
</node>
</node>
</node>
<node CREATED="1715532630466" ID="ID_169592902" MODIFIED="1715533548154" TEXT="mu&#xdf; dazu passenden Builder konzipieren...">
<font NAME="SansSerif" SIZE="12"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1715532833936" ID="ID_1009009693" MODIFIED="1715532840949" TEXT="Problem: Link zum Allocator">
@ -81067,7 +81121,292 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<edge COLOR="#fe0606"/>
<font NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="clanbomber"/>
<node CREATED="1715618831175" HGAP="41" ID="ID_891863283" MODIFIED="1715618893746" STYLE="fork" TEXT="Auswege..." VSHIFT="41">
<edge COLOR="#6a3645" STYLE="linear"/>
<node CREATED="1715618937215" ID="ID_975786159" MODIFIED="1715619229829" TEXT="Tag oder Allocator-Link in jeder Instanz">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
Sorge:
</p>
<ul>
<li>
ich erwarte ~10k Nodes im Modell
</li>
<li>
die meisten Nodes haben nur einen Vorl&#228;ufer / Nachfolger
</li>
</ul>
<p>
&#10233; bl&#228;ht die Storage um 30% auf
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715618955861" ID="ID_189897298" MODIFIED="1715619378057" TEXT="dann halt doch blo&#xdf; Heap-Allokationen machen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
Da der Heap-Allokator inzwischen ziemlich performant ist, k&#246;nnte man damit durchkommen...
</p>
<p>
Sorgen:
</p>
<ul>
<li>
wenn es dann doch Probleme gibt, ist der Zug bereits abgefahren (weil Allokationen &#252;berall im Code passieren)
</li>
<li>
auf anderen Plattformen kann die Performance vom Heap-Allocator ganz anders sein, und wir haben darauf keinerlei Einflu&#223;
</li>
</ul>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715620143727" ID="ID_828708828" MODIFIED="1715620159863" TEXT="Zugriff auf den Allocator per DI (statisch) oder Thread-local"/>
<node CREATED="1715620242056" ID="ID_427769562" MODIFIED="1715620649844" TEXT="Spezieller Allocator mit Block-de-Allocation">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...man verwendet <i>nur speziell im produktiven Einsatz im Node-Graph</i>&#160; 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&#223;-Kenntnis als Ganzes verworfen und neu verwendet wird.
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="forward"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715624536080" ID="ID_614918224" MODIFIED="1715624543338" TEXT="Entscheidungen">
<icon BUILTIN="yes"/>
<node CREATED="1715624583813" ID="ID_1547806624" MODIFIED="1715624601374" TEXT="einfache begin/end-Pointer - Implementierung">
<node CREATED="1715624604522" ID="ID_1995705427" MODIFIED="1715624613764" TEXT="analog zu std::vector"/>
<node CREATED="1715624614444" ID="ID_1920430377" MODIFIED="1715624773441" TEXT="direkt implementieren erscheint sinnvoll">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...weil std::vector zwar bereits alles bietet, aber eingebettet in sehr komplexen Code &#8212; im Besonderen d&#252;rfte es schwierig werden, das Thema on-demand-growth vs non-copyable zu umschiffen
</p>
</body>
</html>
</richcontent>
</node>
</node>
<node CREATED="1715624963026" ID="ID_744219090" MODIFIED="1715624972411" TEXT="separaten Builder f&#xfc;r die zwei Nutz-Muster">
<node CREATED="1715624984553" ID="ID_1271849826" MODIFIED="1715625002785" TEXT="open-sized + move-only"/>
<node CREATED="1715625004020" ID="ID_863474418" MODIFIED="1715625011022" TEXT="fixed-size + noncopyable"/>
</node>
<node CREATED="1715625022874" ID="ID_158782942" MODIFIED="1715625045459" TEXT="Allocator externalisieren (wie in STDL-Containern)"/>
<node CREATED="1715627229164" ID="ID_1793700784" MODIFIED="1715627351601" TEXT="das Concept ist f&#xfc;r sp&#xe4;ter aufgehoben">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...das hei&#223;t, ich gehe mal davon aus, da&#223; ich mit einer einzigen, dedizierten Implementierung erst mal den aktuellen Bedarf decken kann; daraus k&#246;nnte allerdings sp&#228;ter immer noch ein Concept gemacht werden, welches dann alternativ auch durch ScopedCollection oder durch eine embedded-storage-L&#246;sung erf&#252;llt werden kann.
</p>
</body>
</html>
</richcontent>
</node>
</node>
</node>
<node CREATED="1715625068841" ID="ID_273362995" MODIFIED="1715625074791" TEXT="Implementierung">
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1715625094577" ID="ID_1764137888" MODIFIED="1715625115360" TEXT="mu&#xdf; Allocator-Integration kl&#xe4;ren">
<icon BUILTIN="yes"/>
<node CREATED="1715625132676" ID="ID_741455291" MODIFIED="1715625275278" TEXT="bestehende Allocation-Cluster-Impl erscheint nicht ganz passend">
<linktarget COLOR="#fd2206" DESTINATION="ID_741455291" ENDARROW="Default" ENDINCLINATION="371;-21;" ID="Arrow_ID_148841438" SOURCE="ID_748407633" STARTARROW="None" STARTINCLINATION="988;41;"/>
<node CREATED="1715625871491" ID="ID_1677812273" MODIFIED="1715626046458" TEXT="man kann das definitiv passender implementieren">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
heterogene Allokation in eine Sequenz gr&#246;&#223;erer Bl&#246;cke; keinerlei de-Allokation und kein Locking
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715625881800" ID="ID_1460908503" MODIFIED="1715626254822" TEXT="man k&#xf6;nnte aber die bestehende Impl. erst mal ungesehen verwenden">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...sie ist ja fertig und getestet, und wartet seit Jahren auf ihren Einsatz; allerdings w&#228;re ein solches Vorgehen erkl&#228;rungsbed&#252;rftig
</p>
<ul>
<li>
man tut so, als w&#228;re etwas in Ordnung, das nicht in Ordnung ist
</li>
<li>
die bestehende Implementierung ist sogar maximal-d&#228;mlich
</li>
<li>
und bietet zudem keinen guten Pfad zur Weiterentwicklung, sondern m&#252;&#223;te irgendwann ersetzt werden
</li>
<li>
allerdings spielt das Thema vermutlich lange Zeit gar keine Rolle (solange wir nicht sehr gro&#223;e Modelle bauen)
</li>
</ul>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715625901869" ID="ID_460237769" MODIFIED="1715626344549" TEXT="oder aber gleich ganz liegen lassen und blo&#xdf; Heap-Allokationen machen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...<i>wenn man schon </i>die bestehenden Implementierung nutzt (wohl wissend, da&#223; ihre inh&#228;renten Probleme erst mal nicht relevant sind), dann kann man genausogut <i>ganz auf bl&#246;d </i>sich auf den KISS-Standpunkt stellen und einfach Heap-Allokationen machen, denn die sind heutzutage verdammt effizient geworden
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715625929114" ID="ID_704028431" MODIFIED="1715625953412">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
...und alles das l&#228;uft auf weitere <b>technische Schulden</b>&#160;hinaus
</p>
</body>
</html>
</richcontent>
</node>
</node>
<node CREATED="1715626381670" ID="ID_365556330" MODIFIED="1715626396019" TEXT="Idee: den Allocation-Cluster unter gleichem Namen im Grund neu schreiben">
<icon BUILTIN="idea"/>
<node CREATED="1715626414697" ID="ID_280677111" MODIFIED="1715626425820" TEXT="durch den Namen w&#xe4;re die Kontinuit&#xe4;t pro Forma gewahrt"/>
<node CREATED="1715626476945" ID="ID_1929954995" MODIFIED="1715626592916" TEXT="es gibt bisher nur minimale / vorbereitende Verwendungen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...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.
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715626599088" ID="ID_1068758723" MODIFIED="1715626653670" TEXT="das API ist schmal und k&#xf6;nnte inkrementell umgestaltet werden">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...da der davon abh&#228;ngende Code <i>effektiv nur compilierbar ist, aber nicht lauff&#228;hig</i>
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715626710965" ID="ID_1722763351" MODIFIED="1715626721940" TEXT="die neue L&#xf6;sung w&#xe4;re in jedem Fall einfacher">
<node CREATED="1715626738174" ID="ID_714358898" MODIFIED="1715626997202" TEXT="alles Locking f&#xe4;llt weg"/>
<node CREATED="1715626731957" ID="ID_454366756" MODIFIED="1715626737099" TEXT="die Typ-Slots fallen weg"/>
<node CREATED="1715626755683" ID="ID_714015643" MODIFIED="1715626839992" TEXT="das &quot;commit&quot;-Konzept wird aufgegeben">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
let it crash &#8212; wenn tats&#228;chlich eine Exception fliegt, ist es ziemlich wahrscheinlich, da&#223; der ganze Cluster sowiso weggeworfen wird; wenn nicht, dann akzeptieren wir einfach toten Speicher.
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1715626853846" ID="ID_540898270" MODIFIED="1715626985387">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
die Bedeutung ist <b>geringer geworden</b>
</p>
</body>
</html>
</richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
seinerzeit habe ich im AllocationCluster etwas gesehen, da&#223; pervasiv &#252;berall im Code verwendet wird, analog zum Mempool. Inzwischen stehe ich auf dem Standpunkt, da&#223; f&#252;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&#228;ndnis nur noch sinnvoll, wenn sie extrem spezifisch sind
</p>
</body>
</html>
</richcontent>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715627027263" ID="ID_1272289707" MODIFIED="1715627051080" TEXT="Aufgabe: den Standard-Allocator besser verstehen">
<icon BUILTIN="yes"/>
<node CREATED="1715627069918" ID="ID_1496924967" MODIFIED="1715627170299" TEXT="es k&#xf6;nnte n&#xe4;mlich eine Konvergenz geben">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...oder zumindest k&#246;nnte man ein limitiertes Teil-Konzept umsetzen; mir f&#228;llt auf, da&#223; diverse Methoden im Standard-Allocator inzwischen durch Traits ersetzt wurden.
</p>
</body>
</html>
</richcontent>
<node CREATED="1715725369201" ID="ID_1600204256" MODIFIED="1715725381650" TEXT="tats&#xe4;chlich ist es heutzutage sehr einfach"/>
<node CREATED="1715725400796" ID="ID_1894647974" MODIFIED="1715725416576" TEXT="praktisch jeder custom-allocator kann standardkonform gemacht werden">
<icon BUILTIN="idea"/>
</node>
</node>
<node CREATED="1715693133661" ID="ID_868305899" MODIFIED="1715725332461" TEXT="Info zum Allocator-Gebrauch">
<arrowlink COLOR="#4961d5" DESTINATION="ID_152113212" ENDARROW="Default" ENDINCLINATION="-2030;323;" ID="Arrow_ID_717223261" STARTARROW="None" STARTINCLINATION="-1527;135;"/>
<icon BUILTIN="info"/>
</node>
</node>
<node CREATED="1715725538702" ID="ID_321800493" MODIFIED="1715725766650" TEXT="Beschlu&#xdf;">
<arrowlink COLOR="#d50a4b" DESTINATION="ID_1843463730" ENDARROW="Default" ENDINCLINATION="-825;-22;" ID="Arrow_ID_1401304077" STARTARROW="None" STARTINCLINATION="-712;193;"/>
<node CREATED="1715725550356" ID="ID_1829620474" MODIFIED="1715725571045" TEXT="der AllocationCluster wird &#x201e;entkernt&#x201c;"/>
<node CREATED="1715725574935" ID="ID_258954925" MODIFIED="1715725594242" TEXT="umschreiben in einen einfachen linearen Allocator"/>
<node CREATED="1715725607245" ID="ID_551473047" MODIFIED="1715725616887" TEXT="arbeitet auf verketteten Bl&#xf6;cken"/>
<node CREATED="1715725617595" ID="ID_1306733411" MODIFIED="1715725634916" TEXT="diese bekommt man per Delegation an einen Basis-Allocator"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715627195825" ID="ID_40203233" MODIFIED="1715627201745" TEXT="Details festlegen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715625082614" ID="ID_1575150785" MODIFIED="1715625089779" TEXT="SeveralBuilder_test">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
@ -81100,7 +81439,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1715524716035" ID="ID_310789149" MODIFIED="1715524727612" TEXT="wird konkret vom Job aufrgerufen"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823642113" ID="ID_1687015571" MODIFIED="1713823821818" TEXT="TurnoutSystem als Zentral-Element">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823642113" ID="ID_1687015571" MODIFIED="1715623490452" TEXT="TurnoutSystem als Zentral-Element">
<linktarget COLOR="#970836" DESTINATION="ID_1687015571" ENDARROW="Default" ENDINCLINATION="-844;61;" ID="Arrow_ID_1744365913" SOURCE="ID_1779704166" STARTARROW="None" STARTINCLINATION="-187;-10;"/>
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1714997707508" ID="ID_665814613" MODIFIED="1714997710914" TEXT="Analyse">
<icon BUILTIN="flag-yellow"/>
@ -81317,6 +81657,35 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1711549131677" ID="ID_754465017" MODIFIED="1711549140633" TEXT="vorl&#xe4;ufig nutzbare Strukturen bereitstellen ">
<icon BUILTIN="flag-pink"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1682612056884" ID="ID_1219678116" MODIFIED="1715729457579" TEXT="Basis: AllocationCluster/Mem-Manager">
<arrowlink COLOR="#816f7b" DESTINATION="ID_688601712" ENDARROW="Default" ENDINCLINATION="95;-321;" ID="Arrow_ID_1440452458" STARTARROW="None" STARTINCLINATION="-521;38;"/>
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715725466248" ID="ID_1843463730" LINK="https://issues.lumiera.org/ticket/1365" MODIFIED="1715725766650" TEXT="#1365 establish allocation scheme for render nodes">
<linktarget COLOR="#d50a4b" DESTINATION="ID_1843463730" ENDARROW="Default" ENDINCLINATION="-825;-22;" ID="Arrow_ID_1401304077" SOURCE="ID_321800493" STARTARROW="None" STARTINCLINATION="-712;193;"/>
<icon BUILTIN="flag-yellow"/>
</node>
<node COLOR="#338800" CREATED="1715725787852" ID="ID_1127426666" MODIFIED="1715729452446" TEXT="neues einfacheres Interface einbauen">
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1715726296833" ID="ID_320488527" MODIFIED="1715726378902" TEXT="Problem: einzel-Allocator pro Typ">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1715726380325" ID="ID_810607124" MODIFIED="1715726397415" TEXT="f&#xfc;hrt zu hierarchischer Struktur"/>
<node CREATED="1715726517963" ID="ID_1603078940" MODIFIED="1715726538868" TEXT="als nested class mit Zugang zu privaten Methoden"/>
</node>
<node CREATED="1715727163500" ID="ID_164792121" MODIFIED="1715727175958" TEXT="API">
<node CREATED="1715727225764" ID="ID_123722889" MODIFIED="1715727230671" TEXT="getAllocator&lt;TY&gt;"/>
<node CREATED="1715727232648" ID="ID_597499360" MODIFIED="1715727238366" TEXT="create"/>
<node CREATED="1715727250709" ID="ID_886757416" MODIFIED="1715727252348" TEXT="size"/>
<node CREATED="1715728180516" ID="ID_412948320" MODIFIED="1715728191170" TEXT="allot&lt;TY&gt;(cnt)"/>
<node CREATED="1715727255639" ID="ID_1782845675" MODIFIED="1715727439713" TEXT="allotMemory(size_t)"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715725837111" ID="ID_1956366876" MODIFIED="1715725864907" TEXT="Basis-Allocator vorsehen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715725950719" ID="ID_1150594476" MODIFIED="1715725971326" TEXT="Testf&#xe4;lle vereinfachen">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1711549426546" ID="ID_1360717404" MODIFIED="1711549444466" TEXT="ExitNode ausformulieren">
<icon BUILTIN="flag-yellow"/>
@ -81326,6 +81695,10 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1711549606378" ID="ID_343085111" MODIFIED="1711549611378" TEXT="Processing-Node">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715623458395" ID="ID_1779704166" MODIFIED="1715623497615" TEXT="Turnout-System nutzen">
<arrowlink COLOR="#970836" DESTINATION="ID_1687015571" ENDARROW="Default" ENDINCLINATION="-844;61;" ID="Arrow_ID_1744365913" STARTARROW="None" STARTINCLINATION="-187;-10;"/>
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1711552048459" ID="ID_1144247505" MODIFIED="1711552069425" TEXT="brauche Adapter f&#xfc;r den eigentlichen Aufruf">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1711552087622" ID="ID_1064972457" MODIFIED="1711552363214" TEXT="delegieren an die Processing-Function">
@ -81378,7 +81751,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="yes"/>
</node>
<node CREATED="1682612009427" ID="ID_1994458742" MODIFIED="1682612053494" TEXT="vermutlich eine referentielle nicht-intrusive Linked-List">
<node CREATED="1682612056884" ID="ID_303611553" MODIFIED="1682612072158">
<node CREATED="1682612056884" ID="ID_303611553" MODIFIED="1715623658630">
<richcontent TYPE="NODE"><html>
<head/>
<body>
@ -81387,6 +81760,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#816f7b" DESTINATION="ID_688601712" ENDARROW="Default" ENDINCLINATION="95;-321;" ID="Arrow_ID_859179840" STARTARROW="None" STARTINCLINATION="-264;24;"/>
</node>
<node CREATED="1682612075770" ID="ID_1368353614" MODIFIED="1682612084845" TEXT="ein Eintrag kann in mehreren Instanzen der Liste liegen"/>
<node CREATED="1682612094504" ID="ID_250365879" MODIFIED="1682612109226" TEXT="&#x27f9; die umgebaute Liste kann auf einen Schlag aktualisiert werden"/>
@ -81471,12 +81845,19 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
</node>
<node CREATED="1714261516778" ID="ID_1575846856" MODIFIED="1714261522566" TEXT="Control"/>
<node CREATED="1714261516778" ID="ID_1575846856" MODIFIED="1715624338108" TEXT="Control"/>
</node>
</node>
</node>
<node CREATED="1680563454868" ID="ID_1187556686" MODIFIED="1680563459014" TEXT="Backbone"/>
<node CREATED="1680563460649" ID="ID_127710483" MODIFIED="1680563474067" TEXT="MemManagement"/>
<node CREATED="1680563460649" ID="ID_127710483" MODIFIED="1715624384997" TEXT="MemManagement">
<arrowlink COLOR="#454059" DESTINATION="ID_1595450559" ENDARROW="Default" ENDINCLINATION="-1036;-77;" ID="Arrow_ID_1704085390" STARTARROW="None" STARTINCLINATION="-161;430;"/>
<node CREATED="1715623566743" ID="ID_688601712" MODIFIED="1715624494222" TEXT="AllocationCluster">
<linktarget COLOR="#816f7b" DESTINATION="ID_688601712" ENDARROW="Default" ENDINCLINATION="95;-321;" ID="Arrow_ID_859179840" SOURCE="ID_303611553" STARTARROW="None" STARTINCLINATION="-264;24;"/>
<linktarget COLOR="#816f7b" DESTINATION="ID_688601712" ENDARROW="Default" ENDINCLINATION="95;-321;" ID="Arrow_ID_1440452458" SOURCE="ID_1219678116" STARTARROW="None" STARTINCLINATION="-521;38;"/>
</node>
<node CREATED="1715623570769" ID="ID_582193119" MODIFIED="1715623580607" TEXT="Allokations-Verwaltung per Segment"/>
</node>
</node>
<node CREATED="1512923592590" ID="ID_540019681" MODIFIED="1557498707237" TEXT="Engine">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1679783052390" ID="ID_1851394144" MODIFIED="1684869799933" TEXT="gr&#xfc;nden">
@ -121028,7 +121409,11 @@ std::cout &lt;&lt; tmpl.render({&quot;what&quot;, &quot;World&quot;}) &lt;&lt; s
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1711549072833" ID="ID_125061570" MODIFIED="1711549096161" TEXT="Thema: Erweiterbarkeit (Render-Graph)">
<icon BUILTIN="hourglass"/>
</node>
<node CREATED="1711549036030" ID="ID_1875417458" MODIFIED="1711549051408" TEXT="Speicherverwaltung"/>
<node CREATED="1711549036030" ID="ID_1875417458" MODIFIED="1711549051408" TEXT="Speicherverwaltung">
<node CREATED="1715624289964" ID="ID_1595450559" MODIFIED="1715624384997" TEXT="Speicher mit Fixture-Struktur verbunden">
<linktarget COLOR="#454059" DESTINATION="ID_1595450559" ENDARROW="Default" ENDINCLINATION="-1036;-77;" ID="Arrow_ID_1704085390" SOURCE="ID_127710483" STARTARROW="None" STARTINCLINATION="-161;430;"/>
</node>
</node>
</node>
<node CREATED="1681085780230" ID="ID_667166448" MODIFIED="1681085784377" TEXT="Render Toolkit">
<node CREATED="1681085789797" ID="ID_435519695" MODIFIED="1681085821901" TEXT="Abstraktionsschicht &#xfc;ber Low-Level-Funktionalit&#xe4;t"/>
@ -125755,6 +126140,99 @@ std::cout &lt;&lt; tmpl.render({&quot;what&quot;, &quot;World&quot;}) &lt;&lt; s
</node>
</node>
</node>
<node CREATED="1715693174737" ID="ID_152113212" MODIFIED="1715725332461" TEXT="(custom)Allocator">
<linktarget COLOR="#4961d5" DESTINATION="ID_152113212" ENDARROW="Default" ENDINCLINATION="-2030;323;" ID="Arrow_ID_717223261" SOURCE="ID_868305899" STARTARROW="None" STARTINCLINATION="-1527;135;"/>
<node CREATED="1715693298760" ID="ID_1472333314" MODIFIED="1715693300284" TEXT="Quellen">
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1715696253175" ID="ID_267534641" MODIFIED="1715696324289" TEXT="CPP-Referenz">
<icon BUILTIN="info"/>
<node CREATED="1715694999096" ID="ID_360610134" LINK="https://en.cppreference.com/w/cpp/named_req/Allocator" MODIFIED="1715696312832" TEXT="Allocator (named requirement / Concept)">
<icon BUILTIN="back"/>
</node>
<node CREATED="1715695168872" ID="ID_1006356980" LINK="https://en.cppreference.com/w/cpp/memory/allocator_traits" MODIFIED="1715696294384" TEXT="Allocator-Traits (Basis/Adapter f&#xfc;r Allokationen)">
<icon BUILTIN="back"/>
</node>
<node CREATED="1715696264070" ID="ID_1486623180" LINK="https://en.cppreference.com/w/cpp/named_req/AllocatorAwareContainer" MODIFIED="1715696302337" TEXT="Allocator-Aware-Container (definiert die Regeln)">
<icon BUILTIN="back"/>
</node>
<node CREATED="1715700153093" ID="ID_1246505271" LINK="https://en.cppreference.com/w/cpp/memory/allocator" MODIFIED="1715700175680" TEXT="std::allocator">
<font NAME="Monospaced" SIZE="12"/>
</node>
</node>
<node CREATED="1715695327590" ID="ID_1357663133" LINK="https://godbolt.org/z/7fnj1rGr9" MODIFIED="1715695362793" TEXT="lauff&#xe4;higes Beispiel (Godbolt) &#x2014; Vector mit &#xbb;mallocator&#xab;"/>
<node COLOR="#5b280f" CREATED="1715693552823" FOLDED="true" ID="ID_1023319847" LINK="https://www.youtube.com/watch?v=LIb3L4vKZ7U" MODIFIED="1715723921504" TEXT="Alexandrescu CppCon 2015 (video)">
<icon BUILTIN="button_cancel"/>
<node CREATED="1715723719057" ID="ID_978649638" MODIFIED="1715723916920" TEXT="naja ... nur m&#xe4;&#xdf;ig hilfreich">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
viel Gepl&#228;nkel cool-getue; tats&#228;chlich hat er schon einen eigenst&#228;ndigen Gedanken, braucht aber sehr lange, ihn auszuformulieren; und zu den schwierigen praktischen Fragen mit STL-Containern sagt er gar nichts
</p>
</body>
</html></richcontent>
<icon BUILTIN="smiley-angry"/>
</node>
<node CREATED="1715723729266" ID="ID_850299630" MODIFIED="1715723744425" TEXT="er zeigt Design-Schw&#xe4;chen von std::allocator auf (und warum es dazu kam)"/>
<node CREATED="1715723745821" ID="ID_1740554357" MODIFIED="1715723779904">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
dann skizziert er alle wesentlichen Standard-Allocator-Patterns als<i>&#160; composable allocators</i>
</p>
</body>
</html></richcontent>
</node>
</node>
<node CREATED="1715699474963" ID="ID_1114222688" LINK="https://indiegamedev.net/2022/03/27/custom-c20-memory-allocators-for-stl-containers/" MODIFIED="1715699495865" TEXT="Tutorial / Einf&#xfc;hrungsartikel (2022)"/>
<node CREATED="1715701113413" ID="ID_1336731378" LINK="https://github.com/mtrebi/memory-allocators" MODIFIED="1715701155245" TEXT="Standard Allocator-Patterns (Github; Code + Benchmarks)"/>
<node CREATED="1715697734801" ID="ID_860671636" MODIFIED="1715697739055" TEXT="Interessant...">
<node CREATED="1715697740033" ID="ID_1927640605" LINK="https://stackoverflow.com/a/65649845/444796" MODIFIED="1715697750842" TEXT="Allocator mit &#xbb;fancy-pointer&#xab; nutzen"/>
</node>
</node>
<node CREATED="1715693302202" ID="ID_11875709" MODIFIED="1715693310147" TEXT="Grundlagen">
<node CREATED="1715693311183" ID="ID_1432559286" MODIFIED="1715697427063" TEXT="man sollte die std::allocator_traits nutzen (aber nicht erweitern)">
<icon BUILTIN="yes"/>
<node CREATED="1715723947185" ID="ID_98135787" MODIFIED="1715724017929" TEXT="ab C++23 ist Erweitern sogar verboten">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
Begr&#252;ndung: es ist sinnlos, weil das einzige, was man dabei machen kann, ist Fehler machen. Der Standard ist extrem genau und elaboriert f&#252;r dieses Thema, und wenn man sich an wirklich alle Vorgaben h&#228;lt, hat man praktisch keinen Spielraum mehr....
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1715724019592" ID="ID_398818246" MODIFIED="1715724070307" TEXT="sinnvoll ist es den Allocator selber zu schreiben">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...bei Bedarf kann man dort sogar einige optionale Methoden zus&#228;tzlich implementieren, z.B. construct (und das wird dann auch verwendet, anstatt der Standard-Implementierung in den Traits)
</p>
</body>
</html></richcontent>
</node>
</node>
<node CREATED="1715697441488" ID="ID_864300058" MODIFIED="1715697501719" TEXT="Custom-Alloc mu&#xdf; nur allocate(size_t) und deallocate(T*, size_t) implementieren (sowie Equality)"/>
<node CREATED="1715700840370" ID="ID_461698034" MODIFIED="1715700848437" TEXT="Allocator ist entweder stateless oder stateful">
<node CREATED="1715700850389" ID="ID_496751032" MODIFIED="1715700855220" TEXT="ein stateless-Allocator">
<node CREATED="1715700855928" ID="ID_774199988" MODIFIED="1715700862415" TEXT="ist default-constructible"/>
<node CREATED="1715700862910" ID="ID_1738109434" MODIFIED="1715700875953" TEXT="alle Instanzen sind &#xe4;quivalent (opeartor ==)"/>
<node CREATED="1715700876653" ID="ID_1533428462" MODIFIED="1715700884975" TEXT="kann als Template-Parameter definiert werden"/>
</node>
<node CREATED="1715700887866" ID="ID_524521259" MODIFIED="1715700900117" TEXT="ein stateful-Allocator mu&#xdf; als ctor-Parameter verdrahtet werden"/>
</node>
</node>
</node>
<node CREATED="1711405781006" FOLDED="true" ID="ID_135618716" LINK="https://en.cppreference.com/w/cpp/language/class_template_argument_deduction#Deduction_for_class_templates" MODIFIED="1711406693840" TEXT="Deduction Guides (CTAD)">
<linktarget COLOR="#65354c" DESTINATION="ID_135618716" ENDARROW="Default" ENDINCLINATION="21;-62;" ID="Arrow_ID_696408734" SOURCE="ID_1103669600" STARTARROW="None" STARTINCLINATION="-2;93;"/>
<node CREATED="1711405899493" ID="ID_423341464" MODIFIED="1711406049382" STYLE="bubble">