From 130a02102098aa9f6eb613dc75d038e376e38a22 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 7 Jun 2024 22:23:06 +0200 Subject: [PATCH] Library: rearrange storage layout MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In-depth analysis of storage management revealed a misconception with respect to possible storage optimisations, requiring more metadata fields to handle all corner cases correctly. It seems prudent to avoid any but the most obvious optimisations and wait for real-world usage for a better understanding of the prevalent access patterns. However, in preparation for any future optimisations, all access coordination and storage metadata is now relocated into the `ArrayBucket`, and thus resides within the managed allocation, allowing for localised layout optimisations. To place this into context: the expected prevalent use case is for the »Render Nodes Network«, which relies on `AllocationCluster` for storage management; most nodes will have only a single predecessor or successor, leading to a large number of lib::Several intsances populated with a single data element. In such a scenario, it is indeed rather wasteful to allocate four »slot« of metadata for each container instance; even more so since most of this metadata is not even required in such a scenario. --- src/lib/several-builder.hpp | 7 +-- src/lib/several.hpp | 20 +++--- wiki/thinkPad.ichthyo.mm | 120 +++++++++++++++++++++++++++++++++++- 3 files changed, 132 insertions(+), 15 deletions(-) diff --git a/src/lib/several-builder.hpp b/src/lib/several-builder.hpp index 65034f595..55378dada 100644 --- a/src/lib/several-builder.hpp +++ b/src/lib/several-builder.hpp @@ -334,17 +334,16 @@ namespace lib { void adjustSpread (size_t newSpread) { - REQUIRE (Coll::size_); REQUIRE (Coll::data_); REQUIRE (newSpread * Coll::size_ <= storageSiz_); size_t oldSpread = Coll::data_->spread; if (newSpread > oldSpread) // need to spread out - for (size_t i=Coll::size_-1; 0spread = newSpread; @@ -370,7 +369,7 @@ namespace lib { { using Val = typename IT::value_type; size_t elmSiz = sizeof(Val); - adjustStorage (Coll::size_+1, requiredSpread(elmSiz)); + adjustStorage (Coll::size()+1, requiredSpread(elmSiz)); UNIMPLEMENTED ("emplace data"); } diff --git a/src/lib/several.hpp b/src/lib/several.hpp index ab0bb36b8..51e280ef7 100644 --- a/src/lib/several.hpp +++ b/src/lib/several.hpp @@ -78,14 +78,18 @@ namespace lib { struct ArrayBucket { ArrayBucket (size_t elmSize = sizeof(I)) - : deleter{nullptr} + : cnt{0} , spread{elmSize} + , buffSiz{0}//////////////////////////////////////////////////////////////OOO sollte man das nicht besser zwingend korrekt setzen? + , deleter{nullptr} { } - typedef void (*Deleter) (ArrayBucket*, size_t); + typedef void (*Deleter) (ArrayBucket*); - Deleter deleter; + size_t cnt; size_t spread; + size_t buffSiz; + Deleter deleter; /** mark start of the storage area */ alignas(I) @@ -139,13 +143,13 @@ namespace lib { size_t size() const { - return size_; + return data_? data_->cnt : 0; } bool empty() const { - return not (size_ and data_); + return not data_; } I& @@ -155,8 +159,8 @@ namespace lib { return data_->subscript (idx); } - I& front() { return operator[] (size_-1); } - I& back() { return operator[] (0); } + I& front() { return operator[] (data_? data_->size_-1 : 0); } + I& back() { return operator[] (0); } using iterator = I*; using const_iterator = I const*; @@ -174,7 +178,7 @@ namespace lib { discardData() { if (data_ and data_->deleter) - (*data_->deleter) (data_, size_); + (*data_->deleter) (data_); } }; diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index f06efaaf1..b8de516a1 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -81809,6 +81809,51 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + + +

+ Kann derzeit keine befriedigende Lösung für die diversen Zielkonflikte finden. Daher wähle ich eine Lösung, die Raum für zukünftige Lösungen schafft, und aktuell im Basisfall einfach und gradlinig zu implementieren ist. Speicher-Mehrverbrauch für die Metadaten wird in Kauf genommen +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -82162,7 +82207,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + @@ -82345,7 +82391,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -82466,7 +82512,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + @@ -82512,6 +82559,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + @@ -82545,6 +82597,68 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + + + +

+ ...aufgrund der Flexibilität ist das intendierte Verhalten nicht mehr einfach zu fassen; es ist eigens ein Zugangsweg zu finden, um die richtige Logik zu entwickeln--- +

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