Parameters: pick up work on type handling experiments
...after an extended break where I focused on learning IO_URING, which is the topic of my upcoming talk at Froscon-2026; (I built a prototype to read and display video with async IO) Today ''I have re-read my design notes'' and the analysis seems to hold up well; furthermore I solved the coding problem how to generate type handlers for a list of types.
This commit is contained in:
parent
532408a305
commit
82b7acac57
3 changed files with 499 additions and 41 deletions
|
|
@ -41,7 +41,7 @@
|
||||||
|
|
||||||
namespace lib {
|
namespace lib {
|
||||||
namespace par {
|
namespace par {
|
||||||
|
|
||||||
struct ValBuff { /*placeholder*/ };
|
struct ValBuff { /*placeholder*/ };
|
||||||
|
|
||||||
template<typename X>
|
template<typename X>
|
||||||
|
|
@ -60,9 +60,8 @@ namespace par {
|
||||||
return * static_cast<ValBuff const *> (rawMem);
|
return * static_cast<ValBuff const *> (rawMem);
|
||||||
}
|
}
|
||||||
|
|
||||||
template<typename X, class BAS>
|
template<typename X>
|
||||||
class TypeHandler
|
class TypeHandler
|
||||||
: public BAS
|
|
||||||
{
|
{
|
||||||
public:
|
public:
|
||||||
virtual void extractAs (X&, ValBuff&) =0;
|
virtual void extractAs (X&, ValBuff&) =0;
|
||||||
|
|
@ -76,10 +75,11 @@ namespace par {
|
||||||
,uint
|
,uint
|
||||||
,uint64_t
|
,uint64_t
|
||||||
,double
|
,double
|
||||||
|
,float
|
||||||
,bool
|
,bool
|
||||||
>;
|
>;
|
||||||
/** build a generic visitor interface for all types in list */
|
/** build a generic visitor interface for all types in list */
|
||||||
using TypeHandlerInterface = meta::InstantiateChained<BaseTypes::List, TypeHandler>;
|
using TypeHandlerInterface = meta::InstantiateForEach<BaseTypes::List, TypeHandler>;
|
||||||
|
|
||||||
|
|
||||||
/**
|
/**
|
||||||
|
|
@ -99,16 +99,44 @@ namespace par {
|
||||||
virtual ~Domain(); ///< this is an interface
|
virtual ~Domain(); ///< this is an interface
|
||||||
|
|
||||||
protected:
|
protected:
|
||||||
|
|
||||||
};
|
};
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
// GCC > 13 warns at class definition when a new overload shadows an inherited virtual function.
|
||||||
|
// While theoretically correct, in practice any call will be dispatched through the base interface,
|
||||||
|
// which in turn is also generated by metaprogramming from a type list.
|
||||||
|
// See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740
|
||||||
|
_Pragma("GCC diagnostic push") \
|
||||||
|
_Pragma("GCC diagnostic ignored \"-Woverloaded-virtual\"")
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
template<typename U>
|
||||||
|
struct TypeDomainSetup
|
||||||
|
{
|
||||||
|
|
||||||
|
template<typename X, class BAS>
|
||||||
|
class TypeHandlerImpl
|
||||||
|
: public BAS
|
||||||
|
{
|
||||||
|
void
|
||||||
|
extractAs (X& srcVal, ValBuff& valBuff) override
|
||||||
|
{
|
||||||
|
UNIMPLEMENTED ("extract into Buffer");
|
||||||
|
}
|
||||||
|
};
|
||||||
|
|
||||||
|
using TypeHandlerChain = meta::InstantiateChained<BaseTypes::List, TypeHandlerImpl, Domain>;
|
||||||
|
};
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
template<typename X>
|
template<typename X>
|
||||||
class BaseDomain
|
class BaseDomain
|
||||||
: public Domain
|
: public TypeDomainSetup<X>::TypeHandlerChain
|
||||||
{
|
{
|
||||||
void extractAs (uint&, ValBuff& valBuff) override { UNIMPLEMENTED("ex uint"); }
|
public:
|
||||||
void extractAs (double&, ValBuff& valBuff) override { UNIMPLEMENTED("ex double"); }
|
|
||||||
};
|
};
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -92,9 +92,8 @@ namespace test{
|
||||||
uint target1{0};
|
uint target1{0};
|
||||||
CHECK (not target1);
|
CHECK (not target1);
|
||||||
|
|
||||||
// TypeHandler<uint>& dd1{d1};
|
TypeHandler<uint>& dd1{d1};
|
||||||
// dd1.extractAs (target1, src1);
|
dd1.extractAs (target1, src1);
|
||||||
d1.extractAs (target1, src1);
|
|
||||||
CHECK (target1 == uint(val1));
|
CHECK (target1 == uint(val1));
|
||||||
}
|
}
|
||||||
};
|
};
|
||||||
|
|
|
||||||
|
|
@ -81709,6 +81709,23 @@
|
||||||
<font NAME="SansSerif" SIZE="10"/>
|
<font NAME="SansSerif" SIZE="10"/>
|
||||||
</node>
|
</node>
|
||||||
</node>
|
</node>
|
||||||
|
<node COLOR="#5b280f" CREATED="1784472855120" ID="ID_1579989472" MODIFIED="1784473044476" TEXT="STOP. Vorschnelle Schlußfolgerungen vermeiden">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Daß die meisten »Doppelkapseln«, die ich bisher gebaut haben, von einem statischen Anker ausgehen, sagt noch lange nicht, daß die Doppelkapsel-Struktur <i>grundsätzlich ungeeignet wäre! </i>
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
So könnte man die VTable mit einer Typ-ID identifizieren. Im weiteren Verlauf dieser Design-Analyse hat sich das als ein möglicher Pfad herausgebildet (im Besonderen weil ich Platzbeschränkung als leitenden Constraint identifiziert habe)
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<icon BUILTIN="stop-sign"/>
|
||||||
|
</node>
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1782923994701" ID="ID_1564769419" MODIFIED="1782925808566" TEXT="brauche aber trotzdem Typ-Deskriptor">
|
<node CREATED="1782923994701" ID="ID_1564769419" MODIFIED="1782925808566" TEXT="brauche aber trotzdem Typ-Deskriptor">
|
||||||
<arrowlink COLOR="#fdddae" DESTINATION="ID_1301398726" ENDARROW="Default" ENDINCLINATION="40;-63;" ID="Arrow_ID_1797086154" STARTARROW="None" STARTINCLINATION="-278;21;"/>
|
<arrowlink COLOR="#fdddae" DESTINATION="ID_1301398726" ENDARROW="Default" ENDINCLINATION="40;-63;" ID="Arrow_ID_1797086154" STARTARROW="None" STARTINCLINATION="-278;21;"/>
|
||||||
|
|
@ -81806,7 +81823,8 @@
|
||||||
<node CREATED="1782929984851" ID="ID_497737102" MODIFIED="1782929995114" TEXT="und man hat trotzdem ein atomic-Lock"/>
|
<node CREATED="1782929984851" ID="ID_497737102" MODIFIED="1782929995114" TEXT="und man hat trotzdem ein atomic-Lock"/>
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1782928238995" ID="ID_252906942" MODIFIED="1782928251258" TEXT="hier steckt ein concurrency-Problem">
|
<node CREATED="1782928238995" ID="ID_252906942" MODIFIED="1782928251258" TEXT="hier steckt ein concurrency-Problem">
|
||||||
<node CREATED="1782928293464" ID="ID_1896231849" MODIFIED="1782928437789" TEXT="Variante-1 : man erzwingt Static-Init">
|
<node CREATED="1782928293464" ID="ID_1896231849" MODIFIED="1784474158099" TEXT="Variante-1 : man erzwingt Static-Init">
|
||||||
|
<node CREATED="1782928467607" ID="ID_1650429656" MODIFIED="1784474163031" TEXT="erfordert Policy / bzw. Disziplin">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head/>
|
<head/>
|
||||||
<body>
|
<body>
|
||||||
|
|
@ -81815,7 +81833,7 @@
|
||||||
</p>
|
</p>
|
||||||
</body>
|
</body>
|
||||||
</html></richcontent>
|
</html></richcontent>
|
||||||
<node CREATED="1782928467607" ID="ID_1650429656" MODIFIED="1782928479515" TEXT="erfordert Policy / bzw. Disziplin"/>
|
</node>
|
||||||
<node CREATED="1782928480364" ID="ID_838425868" MODIFIED="1782928789999" TEXT="Vorteil: nur eine einzige Indirektion / keine mem-Barrier">
|
<node CREATED="1782928480364" ID="ID_838425868" MODIFIED="1782928789999" TEXT="Vorteil: nur eine einzige Indirektion / keine mem-Barrier">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head/>
|
<head/>
|
||||||
|
|
@ -81879,7 +81897,7 @@
|
||||||
</body>
|
</body>
|
||||||
</html></richcontent>
|
</html></richcontent>
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1782929538698" ID="ID_474931081" MODIFIED="1782929604780" TEXT="Nachteil: die Erst-Verwendung einer neuen Skala stört die global die Concurrency">
|
<node CREATED="1782929538698" ID="ID_474931081" MODIFIED="1782929604780" TEXT="Nachteil: die Erst-Verwendung einer neuen Skala stört global die Concurrency">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head/>
|
<head/>
|
||||||
<body>
|
<body>
|
||||||
|
|
@ -81981,6 +81999,32 @@
|
||||||
<node CREATED="1782933994294" ID="ID_1685235304" MODIFIED="1782934029583" TEXT="ein Deskriptor">
|
<node CREATED="1782933994294" ID="ID_1685235304" MODIFIED="1782934029583" TEXT="ein Deskriptor">
|
||||||
<node CREATED="1782934030343" ID="ID_957407340" MODIFIED="1782934037954" TEXT="typisiert auf einen Basis-Typ"/>
|
<node CREATED="1782934030343" ID="ID_957407340" MODIFIED="1782934037954" TEXT="typisiert auf einen Basis-Typ"/>
|
||||||
<node CREATED="1782934038566" ID="ID_1083259675" MODIFIED="1782934044719" TEXT="die Skala stellt eine Policy dar"/>
|
<node CREATED="1782934038566" ID="ID_1083259675" MODIFIED="1782934044719" TEXT="die Skala stellt eine Policy dar"/>
|
||||||
|
<node CREATED="1784474502116" ID="ID_21486098" MODIFIED="1784474533772" TEXT="könnte hier dynamische Parameter mit integrieren....">
|
||||||
|
<icon BUILTIN="idea"/>
|
||||||
|
<node CREATED="1784474537631" ID="ID_555862966" MODIFIED="1784474550819" TEXT="ein Parameter hätte dann eine Weise der Gegebenheit"/>
|
||||||
|
<node CREATED="1784474555383" ID="ID_1176887105" MODIFIED="1784474574336" TEXT="»vorliegend« wäre dann lediglich der häufigste Spezialfall"/>
|
||||||
|
<node CREATED="1784474575613" ID="ID_929604442" MODIFIED="1784474706120" TEXT="und eine Automations-Auswertung könnte einen lokalen Wert beaufschlagen">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Ein <i>automatisierter</i> Parameter wäre mithin ein Hybrid, wobei ein <i>Anker-Wert</i>  stets lokal vorliegt, man dann aber aus der Automationskurve einen Offset oder Faktor bezieht...
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<icon BUILTIN="forward"/>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1784474736440" ID="ID_560655168" MODIFIED="1784474782036" TEXT="aber Vorsicht ⟹ das führt mehrere Dimensionen von »Deskriptoren« ein">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
das ist dann definitiv nicht mehr <i>bloß ein Typ</i>
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1782934059019" ID="ID_749549250" MODIFIED="1782934107302" TEXT="der Deskriptor wird registriert und dann durch seinen Pointer repräsentiert"/>
|
<node CREATED="1782934059019" ID="ID_749549250" MODIFIED="1782934107302" TEXT="der Deskriptor wird registriert und dann durch seinen Pointer repräsentiert"/>
|
||||||
<node CREATED="1782934126020" ID="ID_309124327" MODIFIED="1782934137620" TEXT="Problem / Aufgabe: Reproduzierbarkeit">
|
<node CREATED="1782934126020" ID="ID_309124327" MODIFIED="1782934137620" TEXT="Problem / Aufgabe: Reproduzierbarkeit">
|
||||||
|
|
@ -82129,7 +82173,7 @@
|
||||||
<node CREATED="1783012595873" ID="ID_774342307" MODIFIED="1783012599113" TEXT="siehe Placement"/>
|
<node CREATED="1783012595873" ID="ID_774342307" MODIFIED="1783012599113" TEXT="siehe Placement"/>
|
||||||
<node CREATED="1783012599911" ID="ID_1341814745" MODIFIED="1783012604808" TEXT="siehe Buffer-Type"/>
|
<node CREATED="1783012599911" ID="ID_1341814745" MODIFIED="1783012604808" TEXT="siehe Buffer-Type"/>
|
||||||
<node CREATED="1783012610651" ID="ID_1372270066" MODIFIED="1783012621604" TEXT="da zeichnet sich ein Muster ab...">
|
<node CREATED="1783012610651" ID="ID_1372270066" MODIFIED="1783012621604" TEXT="da zeichnet sich ein Muster ab...">
|
||||||
<node CREATED="1783012719761" ID="ID_588268047" MODIFIED="1783012738273" TEXT="ein Prototyp und eine DAG aus Bestimmungen"/>
|
<node CREATED="1783012719761" ID="ID_588268047" MODIFIED="1783012719761" TEXT="ein Prototyp und ein DAG aus Bestimmungen"/>
|
||||||
<node CREATED="1783012740594" ID="ID_157784558" MODIFIED="1783012759399" TEXT="beide zusammen werden über ein Query-Rig angebunden"/>
|
<node CREATED="1783012740594" ID="ID_157784558" MODIFIED="1783012759399" TEXT="beide zusammen werden über ein Query-Rig angebunden"/>
|
||||||
<node CREATED="1783012785092" ID="ID_995942771" MODIFIED="1783012793882" TEXT="es gibt verschiedene Formen und Tiefen der Auswertung"/>
|
<node CREATED="1783012785092" ID="ID_995942771" MODIFIED="1783012793882" TEXT="es gibt verschiedene Formen und Tiefen der Auswertung"/>
|
||||||
<node COLOR="#5b280f" CREATED="1783012622480" ID="ID_1896877960" MODIFIED="1783012717685" TEXT="vorerst genügt es, das zu erkennen">
|
<node COLOR="#5b280f" CREATED="1783012622480" ID="ID_1896877960" MODIFIED="1783012717685" TEXT="vorerst genügt es, das zu erkennen">
|
||||||
|
|
@ -82149,7 +82193,7 @@
|
||||||
<node CREATED="1783012849155" ID="ID_1424154331" MODIFIED="1783012870212" TEXT="das »Query-Rig« ist so etwas wie ein Policy-Interface"/>
|
<node CREATED="1783012849155" ID="ID_1424154331" MODIFIED="1783012870212" TEXT="das »Query-Rig« ist so etwas wie ein Policy-Interface"/>
|
||||||
<node CREATED="1783012871777" ID="ID_850184784" MODIFIED="1783012900648" TEXT="darunter liegt ein Schema der Bestimmung in verschiedenen Hinsichtien / Dimensionen"/>
|
<node CREATED="1783012871777" ID="ID_850184784" MODIFIED="1783012900648" TEXT="darunter liegt ein Schema der Bestimmung in verschiedenen Hinsichtien / Dimensionen"/>
|
||||||
<node CREATED="1783012902580" ID="ID_1982594796" MODIFIED="1783012927106" TEXT="Typen sind stets hierarchisch mit Prototyp-Ansatz"/>
|
<node CREATED="1783012902580" ID="ID_1982594796" MODIFIED="1783012927106" TEXT="Typen sind stets hierarchisch mit Prototyp-Ansatz"/>
|
||||||
<node CREATED="1783012935592" ID="ID_722843640" MODIFIED="1783013421499" TEXT="dem »Prototyp« kommt aber ein darüber hinausgehende symbolische Verweisform zu">
|
<node CREATED="1783012935592" ID="ID_722843640" MODIFIED="1784476000114" TEXT="dem »Prototyp« aber kommt eine darüber hinausreichende symbolische Verweisform zu">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head/>
|
<head/>
|
||||||
<body>
|
<body>
|
||||||
|
|
@ -82176,16 +82220,13 @@
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1783012231419" ID="ID_194332924" MODIFIED="1784376447831" TEXT="the Provision">
|
<node CREATED="1783012231419" ID="ID_194332924" MODIFIED="1784376447831" TEXT="the Provision">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head>
|
<head/>
|
||||||
|
|
||||||
</head>
|
|
||||||
<body>
|
<body>
|
||||||
<p>
|
<p>
|
||||||
bestimmt die Art und Weise des Zugriffs auf eine Datenquelle: entweder als Wert der in enem Buffer abgelegt ist, oder als pull von einem Funktor
|
bestimmt die Art und Weise des Zugriffs auf eine Datenquelle: entweder als Wert der in enem Buffer abgelegt ist, oder als pull von einem Funktor
|
||||||
</p>
|
</p>
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html></richcontent>
|
||||||
</richcontent>
|
|
||||||
</node>
|
</node>
|
||||||
</node>
|
</node>
|
||||||
</node>
|
</node>
|
||||||
|
|
@ -82227,12 +82268,12 @@
|
||||||
</p>
|
</p>
|
||||||
</body>
|
</body>
|
||||||
</html></richcontent>
|
</html></richcontent>
|
||||||
<node CREATED="1783013721977" ID="ID_950124427" MODIFIED="1783014286619" TEXT="hier geht auch meine Einsicht bezüglich »Inline-Functor« mit ein">
|
<node CREATED="1783013721977" ID="ID_950124427" MODIFIED="1784476471894" TEXT="hier geht auch meine Einsicht bezüglich »Inline-Functor« mit ein">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head/>
|
<head/>
|
||||||
<body>
|
<body>
|
||||||
<p>
|
<p>
|
||||||
Denn die Design-Analyse hat gezeigt, daß der »Opaque-Buffer«-Ansatz inhaltlich sehr nahe an einer »Inline-Funktion« liegt, und letztere ist aber strukturell am effizientesten zu implementieren als PolymorphicValue — was vor allem an der Notwendigkeit eines »Managers« liegt, um das Instanz- und Copy-Verhalten zu bestimmen. Die Begründung ist, daß ein <i>virtuelles Interface</i> tatsächlich bereits die effizienteste Reallisierung darstellt, sobald es mehrere virtualisierte »methoden« gibt, denn sie faßt das Instanz-Management und den Zugang zu einem gemeinsamen Datenkontext bereits optimal zusammen. Selbst wenn man <i>bewußt nicht die Implementierung aus der C++-Runtime nimmt, </i>(wie im Fall der <font face="Monospaced" color="#6f3636">std::function</font>) so läuft die Struktur doch immer wieder darauf hinaus, Zugang zu einem gemeinsamen Datenpaket zu bekommen (egal ob das nun per PImpl im Heap liegt, oder direkt in einem Inline-Buffer). Denn ohne solchen gemeinsamen Zustand kann es auch kein tangibles Verhalten geben....
|
Denn die Design-Analyse hat gezeigt, daß der »Opaque-Buffer«-Ansatz inhaltlich sehr nahe an einer »Inline-Funktion« liegt, und letztere ist aber strukturell am effizientesten zu implementieren als PolymorphicValue — was im Besonderen an der Notwendigkeit eines »Managers« liegt, um das Instanz- und Copy-Verhalten zu bestimmen. Die Begründung ist, daß ein <i>virtuelles Interface</i> tatsächlich bereits die effizienteste Reallisierung darstellt, sobald es mehrere virtualisierte »Methoden« gibt, denn sie faßt das Instanz-Management und den Zugang zu einem gemeinsamen Datenkontext bereits optimal zusammen. Selbst wenn man <i>bewußt nicht die Implementierung aus der C++-Runtime nimmt, </i>(wie im Fall der <font color="#6f3636" face="Monospaced">std::function</font>) so läuft die Struktur doch immer wieder darauf hinaus, Zugang zu einem gemeinsamen Datenpaket zu bekommen (egal ob das nun per PImpl im Heap liegt, oder direkt in einem Inline-Buffer). Denn ohne solchen gemeinsamen Zustand kann es auch kein tangibles Verhalten geben....
|
||||||
</p>
|
</p>
|
||||||
</body>
|
</body>
|
||||||
</html></richcontent>
|
</html></richcontent>
|
||||||
|
|
@ -82295,6 +82336,12 @@
|
||||||
<node CREATED="1783015147484" ID="ID_1885332452" MODIFIED="1783015170246" TEXT="nicht klar, wie weit das gehen muß"/>
|
<node CREATED="1783015147484" ID="ID_1885332452" MODIFIED="1783015170246" TEXT="nicht klar, wie weit das gehen muß"/>
|
||||||
<node CREATED="1783015171142" ID="ID_579527029" MODIFIED="1783015176294" TEXT="deshalb vertagt">
|
<node CREATED="1783015171142" ID="ID_579527029" MODIFIED="1783015176294" TEXT="deshalb vertagt">
|
||||||
<icon BUILTIN="yes"/>
|
<icon BUILTIN="yes"/>
|
||||||
|
<node COLOR="#5b280f" CREATED="1784478105565" HGAP="22" ID="ID_1344760315" MODIFIED="1784478175523" TEXT="ja — und nein" VSHIFT="5">
|
||||||
|
<font NAME="SansSerif" SIZE="10"/>
|
||||||
|
</node>
|
||||||
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#9c0116" CREATED="1784478137809" ID="ID_1651631052" MODIFIED="1784478170730" TEXT="sollte zumindest klären daß das möglich ist(bleibt)">
|
||||||
|
<font NAME="SansSerif" SIZE="11"/>
|
||||||
|
</node>
|
||||||
</node>
|
</node>
|
||||||
</node>
|
</node>
|
||||||
<node COLOR="#5b280f" CREATED="1783036834486" ID="ID_101058576" MODIFIED="1783036949647" TEXT="Ooops — das paßt jetzt nicht mit dem Type-ID-Pointer zusammen">
|
<node COLOR="#5b280f" CREATED="1783036834486" ID="ID_101058576" MODIFIED="1783036949647" TEXT="Ooops — das paßt jetzt nicht mit dem Type-ID-Pointer zusammen">
|
||||||
|
|
@ -82442,7 +82489,7 @@
|
||||||
<icon BUILTIN="smily_bad"/>
|
<icon BUILTIN="smily_bad"/>
|
||||||
<node CREATED="1783040349995" ID="ID_1865443974" MODIFIED="1783040366820" TEXT="es ist nun weiterhin unklar wie der Typ strukturiert wird"/>
|
<node CREATED="1783040349995" ID="ID_1865443974" MODIFIED="1783040366820" TEXT="es ist nun weiterhin unklar wie der Typ strukturiert wird"/>
|
||||||
<node CREATED="1783040367840" ID="ID_910738575" MODIFIED="1783040393515" TEXT="und wie die Provision platzsparend dargestellt werden kann"/>
|
<node CREATED="1783040367840" ID="ID_910738575" MODIFIED="1783040393515" TEXT="und wie die Provision platzsparend dargestellt werden kann"/>
|
||||||
<node CREATED="1783040405392" ID="ID_1883727059" MODIFIED="1783041074344" TEXT="schlimmer noch: weiß nicht ob diese Performance-Überlegungen überhaupt relevant sind">
|
<node CREATED="1783040405392" ID="ID_1883727059" MODIFIED="1784479444811" TEXT="schlimmer noch: weiß nicht ob diese Performance-Überlegungen überhaupt relevant sind">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head/>
|
<head/>
|
||||||
<body>
|
<body>
|
||||||
|
|
@ -82450,7 +82497,7 @@
|
||||||
nochmal zur Erinnerung: bin in dieses ganze Riesen-Thema nur reingeschlittert, weil ich den processKey als Job-Parameter aufgeben mußte (und der war eine so »schöne Lösung«, die das Thema markiert und auf später verschiebt). Dann habe ich gesagt, einen Zacken nachlegen und mal eben ein Design für Parameter machen. Ich weiß aber noch gar nicht, wo genau die Parameter sonst noch eingesetzt werden sollen. Ich weiß nur, daß ich sie universell einsetzen möchte.
|
nochmal zur Erinnerung: bin in dieses ganze Riesen-Thema nur reingeschlittert, weil ich den processKey als Job-Parameter aufgeben mußte (und der war eine so »schöne Lösung«, die das Thema markiert und auf später verschiebt). Dann habe ich gesagt, einen Zacken nachlegen und mal eben ein Design für Parameter machen. Ich weiß aber noch gar nicht, wo genau die Parameter sonst noch eingesetzt werden sollen. Ich weiß nur, daß ich sie universell einsetzen möchte.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Im Besonderen ist die ganze Auswertung von Parameter komplett ungeklärt. Diese Auswertung passiert irgendwie in Response auf Interaktionen im GUI (vor allem: ändern der Playback-Position, aber natürlich auch direkte Wert-Tweaks). Es ist klar, daß die Auswertung nicht im GUI selber stattfinden wird, denn dafür haben wir die Trennung (die Commands, den UI-Bus und das Event-Sourcing). Wahrscheinlich wird eine Auswertung in einer Projektion der Events passieren, entweder nach einem Builder-Lauf, oder in vielen Fällen anstelle eines Solchen (wenn gar nichts neu gebaut werden muß). Auch der Builder ist ja konzeptionell eine Projektion. Dann aber ist andererseits auch klar, daß Parameter irgendwie in der Render-Engine ausgewerter werden, und zwar dort verpackt in einen Automations-Funktor. Möglicherweise wird diese Auswertung aber auch eine Art <i>compilierte Variante</i> sein.
|
Im Besonderen ist die ganze <i>Auswertung von Parametern</i> komplett ungeklärt. Diese Auswertung passiert irgendwie in Response auf Interaktionen im GUI (vor allem: ändern der Playback-Position, aber natürlich auch direkte Wert-Tweaks). Es ist klar, daß die Auswertung nicht im GUI selber stattfinden wird, denn dafür haben wir die Trennung (die Commands, den UI-Bus und das Event-Sourcing). Wahrscheinlich wird eine Auswertung in einer Projektion der Events passieren, entweder nach einem Builder-Lauf, oder in vielen Fällen anstelle eines Solchen (wenn gar nichts neu gebaut werden muß). Auch der Builder ist ja konzeptionell eine Projektion. Dann aber ist andererseits auch klar, daß Parameter irgendwie in der Render-Engine ausgewerter werden, und zwar dort verpackt in einen Automations-Funktor. Möglicherweise wird diese Auswertung aber auch eine Art <i>compilierte Variante</i> sein.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
|
|
||||||
|
|
@ -82568,9 +82615,7 @@
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1783089184811" ID="ID_1299132056" MODIFIED="1783181849203">
|
<node CREATED="1783089184811" ID="ID_1299132056" MODIFIED="1783181849203">
|
||||||
<richcontent TYPE="NODE"><html>
|
<richcontent TYPE="NODE"><html>
|
||||||
<head>
|
<head/>
|
||||||
|
|
||||||
</head>
|
|
||||||
<body>
|
<body>
|
||||||
<p>
|
<p>
|
||||||
Konsequenz: <b>pull-Prinzip</b> ist verpflichtend
|
Konsequenz: <b>pull-Prinzip</b> ist verpflichtend
|
||||||
|
|
@ -82612,12 +82657,168 @@
|
||||||
<node CREATED="1783182964964" ID="ID_1325516678" MODIFIED="1783182991051" TEXT="Disposition.conform(TY&&)"/>
|
<node CREATED="1783182964964" ID="ID_1325516678" MODIFIED="1783182991051" TEXT="Disposition.conform(TY&&)"/>
|
||||||
</node>
|
</node>
|
||||||
</node>
|
</node>
|
||||||
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1784480336698" ID="ID_440800496" MODIFIED="1784480356903" TEXT="Spielräume">
|
||||||
|
<icon BUILTIN="yes"/>
|
||||||
|
<icon BUILTIN="forward"/>
|
||||||
|
<node CREATED="1784480360439" ID="ID_1260735860" MODIFIED="1784480368981" TEXT="nicht zu sehr verrückt machen....">
|
||||||
|
<icon BUILTIN="ksmiletris"/>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1784480371646" ID="ID_74554440" MODIFIED="1784480388324">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
»klein« heißt nicht <i>wirklich klein</i>
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<node CREATED="1784480390644" ID="ID_1402184236" MODIFIED="1784480408676" TEXT="ein «Slot» ≙ 8 Byte"/>
|
||||||
|
<node CREATED="1784480433845" ID="ID_705502812" MODIFIED="1784480445354" TEXT="bereits ein double-Wert braucht einen weiteren Slot"/>
|
||||||
|
<node CREATED="1784480464257" ID="ID_1171181752" MODIFIED="1784480955078" TEXT="für einen halbwegs »generischen« Parameter sind wir in der Größenordnung eines std::string">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Es wäre denkbar, eine unter-Klasse der Parameter zu bilden, die dann <i>reine Werte</i> sind. Die könnte man auf 2 «Slots» limitieren. Alles, was darüber hinausgeht ist zwangsläufig ein flexibel belegter, lokaler Container. Und da wir <i>definitiv</i> so etwas wie »generische Parameter« als einen Datentyp haben wollen, muß der Inline-Buffer groß genug sein, um darin zumindest einen Delegations-Mechanismus zu realisieren, oder eben doch ein paar Flags mit abzulegen. Außerdem gewinnt man bei diesen Trade-Offs typischerweise nicht viel, wenn man von 2-er-Potenzen abweicht, denn die Alignments auf 2, 4, oder 8 Slots sind allgegenwärtig; eine Cache-Line hat typischerweise 64 Slots (64 x 64bit). Mein Bauchgefühlt sagt mir, 3 Slots bringen überhaupt nichts (gegenüber 4 Slots), aber über 5 statt 8 könnte man reden.
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node BACKGROUND_COLOR="#c8c0b6" CREATED="1784480957118" ID="ID_271247937" MODIFIED="1784481060756" STYLE="bubble">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
<u><font color="#3d1a77">Vorurteil</font></u>: 4 «Slots» ≙ <b><font color="#530c0c">32</font> Bytes</b>
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<icon BUILTIN="forward"/>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
|
<node BACKGROUND_COLOR="#f9f4b9" COLOR="#451874" CREATED="1784481079566" ID="ID_1735949891" MODIFIED="1784481713695">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Trade-Off-Ansatz: »<b>statische Basisklassen</b>«
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<icon BUILTIN="idea"/>
|
||||||
|
<node CREATED="1784481116929" ID="ID_1988682814" MODIFIED="1784481201124">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
natürlich weiterhin ein klassisches, <b>virtuelles Interface</b>
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1784481126125" ID="ID_763928468" MODIFIED="1784481174734">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
aber die Basisklassen-Instanz hat keine zusätzlichen <b>Laufzeit-Daten</b>
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1784481135575" ID="ID_611313643" MODIFIED="1784481165217">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
vielmehr wurde sie per <b>Template-Metaprogramming</b> generiert
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1784481263694" ID="ID_858590367" MODIFIED="1784481399604" TEXT="alle »Eigenschaften« sind als virtuelle Funktion zugänglich">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Wofür man zunächst in der klassichen OO-Programmierung ein privates Datenfeld einsetzen würde, wird hier als ein statisches privates Datenfeld repräsentiert, das direkt (oder indirekt) über eine Interface-Methode zugänglich ist. Die Auslegung und Parametrisierung der Basisklasse erfolgt also <i>zur Compile-time.</i>
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1784481228034" ID="ID_742661193" MODIFIED="1784481677627" TEXT="Preis: kombinatorische Explosion im Code-Segment">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Jede, wirklich jede Ausprägungs-Variante schlägt sich nieder in Form einiter (deduplizierter) Datenfelder in einem Daten-Segment (private static), sowie einem <b>kompletten</b> Satz an Methoden-Implementierungen im Code-Segment, und einer VTable mit Zeigern auf diese. Muß man eine weitere Methode ins Interface aufnehmen, entsteht sofort ein starker Hebel...
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
So ein Ansatz wäre vertretbar, wenn letztlich die Anzahl der Ausprägungen doch überschaubar bleibt, davon aber sehr viele Einzelinstanzen existieren. Im Besonderen müßte man darauf achten, daß Finite-Domain bzw. Enummerationen dann doch noch einmal kaskadierend herausgezogen werden — oder eben doch wenigstens per ID in den Payload-Daten referenziert sind.
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<icon BUILTIN="messagebox_warning"/>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1783092313541" ID="ID_414920838" MODIFIED="1783092329207" TEXT="das legt den Entwurf (vorerst) ausreichend fest">
|
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1783092313541" ID="ID_414920838" MODIFIED="1783092329207" TEXT="das legt den Entwurf (vorerst) ausreichend fest">
|
||||||
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
||||||
<icon BUILTIN="yes"/>
|
<icon BUILTIN="yes"/>
|
||||||
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#ac1b01" CREATED="1784481754220" ID="ID_357858713" MODIFIED="1784481818217">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
<u>Aufgabe</u> ist nun: Bausteine skizzieren
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<font NAME="SansSerif" SIZE="11"/>
|
||||||
|
</node>
|
||||||
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#ac1b01" CREATED="1784481773524" ID="ID_50851004" MODIFIED="1784481801844" TEXT="eine Machbarkeits-Studie">
|
||||||
|
<font NAME="SansSerif" SIZE="11"/>
|
||||||
|
</node>
|
||||||
</node>
|
</node>
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1783092339601" ID="ID_121697070" MODIFIED="1783092342652" TEXT="nun aufzubauen">
|
<node CREATED="1783092339601" ID="ID_121697070" MODIFIED="1783092342652" TEXT="nun aufzubauen">
|
||||||
|
<node COLOR="#322980" CREATED="1784481861979" ID="ID_1854009134" MODIFIED="1784482631679">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
<b><font size="4">Vorentwurf</font></b>(Zusammenfassung):
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<icon BUILTIN="forward"/>
|
||||||
|
<node CREATED="1784481879651" ID="ID_1091882528" MODIFIED="1784481929912" TEXT="par::Parameter ist ein Polymorphic-Value + Front-end-Funktionen"/>
|
||||||
|
<node CREATED="1784481938579" ID="ID_1702499411" MODIFIED="1784481966368" TEXT="Im Container liegt eine Disposition (≙ OO-Interface)"/>
|
||||||
|
<node CREATED="1784482171445" ID="ID_1336361533" MODIFIED="1784482183591" TEXT="Variationsmöglichkeit per »statischer Basisklasse«"/>
|
||||||
|
<node CREATED="1784482185860" ID="ID_1609655650" MODIFIED="1784484698919" TEXT="Aber der erste Entwurf verwendet eine packed-ID">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Diese kombiniert verschiedene Registrierungs-Indices, möglicherweise für die Base-Domain, einen (Domain)Prototype und/oder eine Scale. Denkbar wäre auch, hier noch ein »Schema« einzuführen, um ggfs direkt, an der VTable vorbei, gewisse Zugriffs-Schemata direkt über die Front-end-Funktionen zu realisieren (wobei im Moment nicht klar ist ob sowas überhaupt sinnvoll ist, und dann nicht doch gleich ein anderer statischer Basistyp angemessener wäre)
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1784482541002" ID="ID_1545323850" MODIFIED="1784482587667">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
die Größe ist insgesamt auf <b><font color="#8b0264">32</font> Bytes</b> fest limitiert
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
<node CREATED="1783092344401" ID="ID_723247866" MODIFIED="1783092356166" TEXT="ParamType">
|
<node CREATED="1783092344401" ID="ID_723247866" MODIFIED="1783092356166" TEXT="ParamType">
|
||||||
<node CREATED="1783092477119" ID="ID_1734714581" MODIFIED="1783092481906" TEXT="Interfaface">
|
<node CREATED="1783092477119" ID="ID_1734714581" MODIFIED="1783092481906" TEXT="Interfaface">
|
||||||
<node CREATED="1783092482966" ID="ID_1196126403" MODIFIED="1783092486026" TEXT="virtuell"/>
|
<node CREATED="1783092482966" ID="ID_1196126403" MODIFIED="1783092486026" TEXT="virtuell"/>
|
||||||
|
|
@ -82661,39 +82862,129 @@
|
||||||
<node CREATED="1783098358531" ID="ID_1280505955" MODIFIED="1783098443001" TEXT="Type-Sequenz der erlaubten Basis-Typen">
|
<node CREATED="1783098358531" ID="ID_1280505955" MODIFIED="1783098443001" TEXT="Type-Sequenz der erlaubten Basis-Typen">
|
||||||
<linktarget COLOR="#662940" DESTINATION="ID_1280505955" ENDARROW="Default" ENDINCLINATION="1362;-81;" ID="Arrow_ID_157492531" SOURCE="ID_836781666" STARTARROW="None" STARTINCLINATION="133;501;"/>
|
<linktarget COLOR="#662940" DESTINATION="ID_1280505955" ENDARROW="Default" ENDINCLINATION="1362;-81;" ID="Arrow_ID_157492531" SOURCE="ID_836781666" STARTARROW="None" STARTINCLINATION="133;501;"/>
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1783209319403" ID="ID_571533481" MODIFIED="1783209758676" TEXT="Code-technische Schwierigkeiten">
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1783209319403" ID="ID_571533481" MODIFIED="1784492334714" TEXT="Code-technische Schwierigkeiten">
|
||||||
<icon BUILTIN="messagebox_warning"/>
|
<icon BUILTIN="messagebox_warning"/>
|
||||||
<node CREATED="1783209333347" ID="ID_1718416802" MODIFIED="1783209352373" TEXT="GCC warnt wegen Ambiguität">
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#6b0990" CREATED="1783209333347" ID="ID_1718416802" MODIFIED="1784492354321" TEXT="GCC warnt wegen Ambiguität">
|
||||||
<node CREATED="1783209353662" ID="ID_1454319261" MODIFIED="1783209468214" TEXT="der multiple-mix-in-Ansatz funktioniert gar nicht (mehr)">
|
<icon BUILTIN="broken-line"/>
|
||||||
|
<node COLOR="#5b280f" CREATED="1783209353662" ID="ID_1454319261" MODIFIED="1784489442770" TEXT="der multiple-mix-in-Ansatz funktioniert gar nicht (mehr)">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head>
|
<head/>
|
||||||
|
|
||||||
</head>
|
|
||||||
<body>
|
<body>
|
||||||
<p>
|
<p>
|
||||||
...interessanterweise auch nicht (mehr) beim Variant-Visitor: auch dort habe ich in die Zugriffsfunktion schon vor einiger Zeit einen Upcast auf das Type-Handler-Interface eingebaut. Der Compiler erlaubt anscheinend nicht mehr, verschiedene Overloads einer gleich benannten Funktion aus mehreren Basisklassen zusammenzuführen
|
...interessanterweise auch nicht (mehr) beim Variant-Visitor: auch dort habe ich in die Zugriffsfunktion schon vor einiger Zeit einen Upcast auf das Type-Handler-Interface eingebaut. Der Compiler erlaubt anscheinend nicht mehr, verschiedene Overloads einer gleich benannten Funktion aus mehreren Basisklassen zusammenzuführen
|
||||||
</p>
|
</p>
|
||||||
</body>
|
</body>
|
||||||
</html></richcontent>
|
</html></richcontent>
|
||||||
|
<icon BUILTIN="button_cancel"/>
|
||||||
|
<node BACKGROUND_COLOR="#c8c0b6" CREATED="1784489444352" ID="ID_1412623970" MODIFIED="1784489521150" TEXT="doch! das funktioniert weiterhin">
|
||||||
|
<icon BUILTIN="idea"/>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1784489483382" ID="ID_617432070" MODIFIED="1784491530502" TEXT="allerdings darf der Aufruf selber keine Ambiguität erzueugen...">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Kann jetzt nur <i>spekulieren, warum ich da seinerzeit eine Fehlermeldung </i>hatte. Könnte an dem vorläufigen Stand der Test-Implementierung damals liegen, denn ich wollte compilieren, ohne bereits die Implementierungs-Chain zu definieren (was ich erst jetzt kann, nachdem ich auf den Trick mit dem Typ-Parameter im umschließenden Scope gekommen bin) — hatte also explizite Implementierungen geschrieben.
|
||||||
|
</p>
|
||||||
|
<h2>
|
||||||
|
Experimente mit Varianten
|
||||||
|
</h2>
|
||||||
|
<p>
|
||||||
|
Es zeigt sich, daß dieses Konstrukt den Compiler in eine komplexe Situation bringt, in der wirklich jedes Detail stimmig sein muß. Im Besonderen kann die Diagnostik komplett irreführend sein; wenn etwas mit der Sichtbarkeit nicht stimmt, kommt es zu einer (verdeckten) Ambiguität, die u.U. (abhängig vom konkreten Typ) automatisch vom Compiler „repariert“ wird (ich meine diese problematischen Regeln, daß z.B. ein unsigned an vielen Stellen geräuschlos auf einen Signed zugewiesen werden kann). Außerdem ist es wichtig, das Pragma zum Unterdrücken von <font color="#6a3728" face="Monospaced">-Woverloaded-virtual</font> bereits <i>vor</i>  dem Template stehen muß, in dem das Shaddowing auftritt (nicht etwa, wie man intuitiv erwarten würde, vor der Verwendung).
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
In diesen Experimenten erscheint dann doch das ursprüngliche Baumuster von Alexandrescu die stabilste Lösung zu sein. Also ein multiple-mix-in für das Interface, aber eine Kette für die Implementierung. Das liegt daran, daß dann eine eventuelle Ambiguität beim Aufruf wirklich direkt im Interface passiert, nicht irgendwo in einer Kette; hinzu kommt, daß wir in einer Kette die Sichtbarkeit explizit wieder herstellen müssen durch ein <font face="Monospaced">using </font><font color="#921717" face="Monospaced">BAS</font><font color="#5f4e4e" face="Monospaced">::functionname</font><font face="Monospaced">;</font> — und das kann weitere Ambiguitäten erzeugen, und erfordert vor allem irgendwo eine catch-all-Definition (z.B. mit leerer Argumentliste). Das ist verwirrend und kann weitere Ambiguitäten erzeugen.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
Wenn der Compiler irgendwo automatisch (falsch) konvertiert, kann es dann zu völlig verwirrenden anderen Problemen kommen, wie z.B. der Zugriff über eine Referenz auf ein Objekt anderen Typs (was nur mit einer const-Referenz erlaubt ist).
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
<i>Insofern verstehe ich durchaus die Motivation, warum </i><font face="Monospaced" color="#692727">-Woverloaded-virtual</font><i>  eingeführt wurde; hier gibt es viele Fallen, die einen unerfahren Programmierer vor unlösbare Probleme stellen können</i>
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<linktarget COLOR="#ffe99c" DESTINATION="ID_617432070" ENDARROW="Default" ENDINCLINATION="236;9;" ID="Arrow_ID_1412212027" SOURCE="ID_711986937" STARTARROW="None" STARTINCLINATION="236;9;"/>
|
||||||
|
</node>
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1783209469407" ID="ID_490480880" MODIFIED="1783209607495" TEXT="mit einer linearisierten Vererbunskette gibt's lediglich eine Warnung">
|
<node CREATED="1783209469407" ID="ID_490480880" MODIFIED="1783209607495" TEXT="mit einer linearisierten Vererbunskette gibt's lediglich eine Warnung">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head>
|
<head/>
|
||||||
|
|
||||||
</head>
|
|
||||||
<body>
|
<body>
|
||||||
<p>
|
<p>
|
||||||
...auch das Problem kenne ich schon: -Woverloaded-virtual : da hatten die Compiler-Entwickler durchaus relevante Gefahren im Blick, aber haben die Warnung zu billig implementiert, nämlich bereits bei der Definition eines überladenen Virtual. Die Gefahr würde jedoch erst beim zweideutigen Aufruf bestehen. Daher kann man diese Warnung per Pragma übersteuern. Hab ich bereits bei verschiedenen Verwendungen des Generator-Templates getan.
|
...auch das Problem kenne ich schon: -Woverloaded-virtual : da hatten die Compiler-Entwickler durchaus relevante Gefahren im Blick, aber haben die Warnung zu billig implementiert, nämlich bereits bei der Definition eines überladenen Virtual. Die Gefahr würde jedoch erst beim zweideutigen Aufruf bestehen. Daher kann man diese Warnung per Pragma übersteuern. Hab ich bereits bei verschiedenen Verwendungen des Generator-Templates getan.
|
||||||
</p>
|
</p>
|
||||||
</body>
|
</body>
|
||||||
</html></richcontent>
|
</html></richcontent>
|
||||||
|
<node CREATED="1784489651047" ID="ID_780658502" MODIFIED="1784490820223" TEXT="die man (derzeit?) mit GCC-Pragma unterdrücken muß">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<div style="background-color: #eee0b5; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 2px">
|
||||||
|
<div style="color: #202020; background-color: #eee0b5; font-family: DejaVu Sans Mono; font-size: 9pt; white-space: pre">
|
||||||
|
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
|
||||||
|
<font color="#977b75">// GCC > 13 warns at class definition when a new overload shadows an inherited virtual function.</font>
|
||||||
|
</p>
|
||||||
|
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
|
||||||
|
<font color="#977b75">// While theoretically correct, in practice any call will be dispatched through the base interface,</font>
|
||||||
|
</p>
|
||||||
|
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
|
||||||
|
<font color="#977b75">// which in turn is also generated by metaprogramming from a type list.</font>
|
||||||
|
</p>
|
||||||
|
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
|
||||||
|
<font color="#977b75">// See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740</font>
|
||||||
|
</p>
|
||||||
|
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
|
||||||
|
<font color="#3a1f18">_Pragma</font><font color="#11123a">(</font><font color="#996e62"><i>"GCC diagnostic push"</i></font><font color="#11123a">)</font><font color="#3a1f18"> </font><font color="#65533c">\</font>
|
||||||
|
</p>
|
||||||
|
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
|
||||||
|
<font color="#3a1f18">_Pragma</font><font color="#11123a">(</font><font color="#996e62"><i>"GCC diagnostic ignored \"-Woverloaded-virtual\""</i></font><font color="#11123a">)</font>
|
||||||
|
</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
<p>
|
||||||
|
<br />
|
||||||
|
<u>Wichtig</u>: muß bereits <b>vor</b> dem Template stehen, in dem das Shaddowing auftritt (kann aber durchaus mitten in einem Namespace sein)
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1784489714610" ID="ID_626901816" MODIFIED="1784490126318" TEXT="interessanterweise ist nichteinmal ein using BASE::extractAs notwendig">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
...denn an der Stelle spielt Sichtbarkeit gar keine Rolle mehr, es wird nur eine schon vorhandene Interface-Methode in der VTable auf eine konkrete Implementierung gebunden. Allerdings <b>nur</b>, wenn man tatsächlich das Interface als multiple-mix-in generiert — denn das <i>umgeht das Sichtbarkeits-Problem</i>
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
|
<node COLOR="#352c84" CREATED="1784491298401" ID="ID_427305032" MODIFIED="1784491357026" TEXT="Fazit {generiertes Mulit-TypeHandler-OO-Interface}">
|
||||||
|
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
|
||||||
|
<icon BUILTIN="forward"/>
|
||||||
|
<node CREATED="1784491360016" ID="ID_711986937" MODIFIED="1784491537887" TEXT="das Original-Baumuster von Alexandrescu ist immer noch die beste Lösung">
|
||||||
|
<arrowlink COLOR="#ffe99c" DESTINATION="ID_617432070" ENDARROW="Default" ENDINCLINATION="236;9;" ID="Arrow_ID_1412212027" STARTARROW="None" STARTINCLINATION="236;9;"/>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1784491373675" ID="ID_1952132123" MODIFIED="1784491392120" TEXT="die Implementierung per Chain braucht keine Sichtbarkeit der anderen Overloads"/>
|
||||||
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1784491392987" ID="ID_1626670078" MODIFIED="1784491428279" TEXT="auf Ambiguitäten in den Typ-Signaturen achten">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Das größte Problem sind die automatischen Umwandlungen von Basis-Typen in C++
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<icon BUILTIN="clanbomber"/>
|
||||||
|
</node>
|
||||||
</node>
|
</node>
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1783209608510" ID="ID_703553750" MODIFIED="1783209752232" TEXT="muß dem Implementierungs-Template einen zusätzlichen Typ-Parameter zukommen lassen">
|
<node CREATED="1783209608510" ID="ID_703553750" MODIFIED="1783209752232" TEXT="muß dem Implementierungs-Template einen zusätzlichen Typ-Parameter zukommen lassen">
|
||||||
<richcontent TYPE="NOTE"><html>
|
<richcontent TYPE="NOTE"><html>
|
||||||
<head>
|
<head/>
|
||||||
|
|
||||||
</head>
|
|
||||||
<body>
|
<body>
|
||||||
<p>
|
<p>
|
||||||
das ist kniffelig, da das ein template-template-Parameter ist, mit zwei bereits festgelegten Typ-Parametern (Zieltyp und Basisklasse). Hier implementieren wir aber Domain<X>, also muß der Quell-Parameter X auch irgendiw zusätzlich in den Type-Handler gebracht werden. Idee: als nested-Templates definieren und dann am Ende per templated Typedef rausziehen
|
das ist kniffelig, da das ein template-template-Parameter ist, mit zwei bereits festgelegten Typ-Parametern (Zieltyp und Basisklasse). Hier implementieren wir aber Domain<X>, also muß der Quell-Parameter X auch irgendiw zusätzlich in den Type-Handler gebracht werden. Idee: als nested-Templates definieren und dann am Ende per templated Typedef rausziehen
|
||||||
|
|
@ -152794,10 +153085,150 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
||||||
<icon BUILTIN="bell"/>
|
<icon BUILTIN="bell"/>
|
||||||
<node CREATED="1778113251791" ID="ID_719985737" MODIFIED="1778113329577" TEXT="Basis: Async-IO (IO_URING)">
|
<node CREATED="1778113251791" ID="ID_719985737" MODIFIED="1778113329577" TEXT="Basis: Async-IO (IO_URING)">
|
||||||
<arrowlink COLOR="#323ccd" DESTINATION="ID_513273421" ENDARROW="Default" ENDINCLINATION="-1630;-298;" ID="Arrow_ID_1806410644" STARTARROW="None" STARTINCLINATION="-1524;159;"/>
|
<arrowlink COLOR="#323ccd" DESTINATION="ID_513273421" ENDARROW="Default" ENDINCLINATION="-1630;-298;" ID="Arrow_ID_1806410644" STARTARROW="None" STARTINCLINATION="-1524;159;"/>
|
||||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1779805310242" ID="ID_478770549" MODIFIED="1779805815322" TEXT="Mai26: bewerbe mich für einen FrOSCon-Vortrag über dieses Thema">
|
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1779805310242" ID="ID_478770549" MODIFIED="1783968789239" TEXT="Mai26: bewerbe mich für einen FrOSCon-Vortrag über dieses Thema (akzeptiert)">
|
||||||
<arrowlink COLOR="#ac193d" DESTINATION="ID_1356755436" ENDARROW="Default" ENDINCLINATION="-2519;165;" ID="Arrow_ID_1080225006" STARTARROW="None" STARTINCLINATION="-2364;98;"/>
|
<arrowlink COLOR="#ac193d" DESTINATION="ID_1356755436" ENDARROW="Default" ENDINCLINATION="-2519;165;" ID="Arrow_ID_1080225006" STARTARROW="None" STARTINCLINATION="-2364;98;"/>
|
||||||
<icon BUILTIN="bell"/>
|
<icon BUILTIN="bell"/>
|
||||||
</node>
|
</node>
|
||||||
|
<node CREATED="1783468862456" ID="ID_1034005387" MODIFIED="1783468882878" TEXT="Vorläufige Einsichten">
|
||||||
|
<icon BUILTIN="idea"/>
|
||||||
|
<node CREATED="1783468898190" ID="ID_1475247705" MODIFIED="1783468930846" TEXT="io_uring markiert die Jobs mit einem Kontext-Pointer">
|
||||||
|
<node CREATED="1783468937958" ID="ID_1565848180" MODIFIED="1783468989732" TEXT="das paßt perfekt auf die geplanten »Continuations«">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
...die hatte ich intuitiv so angelegt, weil ich schon vermutet habe, daß »man« ein asynchrones IO-Interface so definiert....
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783469012311" ID="ID_1044169368" MODIFIED="1783469057752" TEXT="ein Problem der Konstruktion ist aber, wie die Completion-Entries gehandhabt werden">
|
||||||
|
<icon BUILTIN="messagebox_warning"/>
|
||||||
|
<node CREATED="1783469074326" ID="ID_932942159" MODIFIED="1783469080817" TEXT="wir wollen keinen Reaktor-Thread">
|
||||||
|
<node CREATED="1783469111721" ID="ID_405029887" MODIFIED="1783469111721">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
weil dann wieder ein zentraler Verteiler da wäre, der andere Threads antriggern müßte
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783469115153" ID="ID_559476903" MODIFIED="1783469132499" TEXT="oder der neue Jobs in den Scheduler einspeisen müßte"/>
|
||||||
|
<node CREATED="1783469133423" ID="ID_1627275429" MODIFIED="1783469142818" TEXT="oder Jobs am Scheduler vorbei auslösen müßte"/>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783469162550" ID="ID_1178541379" MODIFIED="1783469171910" TEXT="konsequenterweise müßten die Worker das selber machen"/>
|
||||||
|
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1783469172986" ID="ID_1986009047" MODIFIED="1783469190808" TEXT="dann ist aber das praktische Problem: wie verteilt man die Last?">
|
||||||
|
<icon BUILTIN="help"/>
|
||||||
|
<node CREATED="1783469200423" ID="ID_1975068205" MODIFIED="1783469213993" TEXT="es könnten auf einmal jede Menge CQ-Entries da sein"/>
|
||||||
|
<node CREATED="1783469317962" ID="ID_942113151" MODIFIED="1783469338513" TEXT="wir sehen nicht, welcher dieser Continuations am dringensten ist"/>
|
||||||
|
<node CREATED="1783469379035" ID="ID_1417098709" MODIFIED="1783469502430" TEXT="das Abräumen und triggern einer Continuation allein ist zu wenig für einen Job-Zyklus">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Will sagen: wenn man sich einen Completion-Entry nimmt, dann weiß man erst noch nicht, ob daraus nur das dekrementieren einer Gate-Activity folgt, oder ob das direkt in einen aufwendigen Computation-Job mündet. Ein reines Triggern geht sehr schnell, und steht in keinem Verhältnis zum Overhead, den ein Worker durchläuft, bis er den nächsten Job hat
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1783469504485" ID="ID_1115841193" MODIFIED="1783469719178" TEXT="⟹ die Frage ist: wann droppt man das Grooming-Token?">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Solange ein Job aus der Completion-Queue entnimmt, muß er das Grooming-Token haben, weil die Ringbuffer von io_uring nur single-Producer/Consumer-fähig sind. Man müßte also irgendwie feststellen können, ob ein Entry tatsächlich in die Verarbeitung eines Calculation-Jobs mündet. Denn dann könnte man bis dorthin arbeiten, dann das Grooming-Token droppen, und in diesen Job einsteigen. Das wäre dann konsistent mit unserer Architektur: der nächste Job hätte dann die nächsten anstehenden Completion-Entries zu bearbeiten.
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783469737866" ID="ID_1720621872" MODIFIED="1783469766981">
|
||||||
|
<richcontent TYPE="NODE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
<u>Konsequenz</u>: Prüfung und <b>Priorisierung</b> der Completions notwendig
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<icon BUILTIN="forward"/>
|
||||||
|
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1783469820544" ID="ID_227034303" MODIFIED="1783469844240" TEXT="muß mir die Konstruktion von Gates und Triggern daraufhin ansehen">
|
||||||
|
<icon BUILTIN="yes"/>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
|
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1783968668546" ID="ID_107626150" LINK="https://claude.ai/share/2d09d5e6-1a47-45e9-b05b-500550fb0977" MODIFIED="1783968913377" STYLE="fork" TEXT="Design/Architektur-Dialog mit Claude zum Thema IO_URING">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Größtenteils um das Design für die Demo-Applikation festzulegen, die ich derzeig für den FrOSCon-Talk (IO_uring für Video-Widergabe) entwickle
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
|
||||||
|
<icon BUILTIN="wizard"/>
|
||||||
|
<node CREATED="1783968139661" ID="ID_721741944" MODIFIED="1783968157925" TEXT="Proactor ist push — unsere Architektur ist konsistent pull"/>
|
||||||
|
<node COLOR="#5b280f" CREATED="1783968173638" ID="ID_1363800541" MODIFIED="1783968193807" TEXT="man sollte nicht versuchen, einen Proactor in unser Design zu integrieren">
|
||||||
|
<icon BUILTIN="stop-sign"/>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783968195246" ID="ID_1729925953" MODIFIED="1783968212467" TEXT="stattdessen kann man die Proactor-Loop in Activities oder Jobs packen"/>
|
||||||
|
<node CREATED="1783968233008" ID="ID_1599145728" MODIFIED="1783968259313" TEXT="Auf Engine-Level: Zugang zum URing muß in der »Grooming-Zone« bleiben">
|
||||||
|
<icon BUILTIN="messagebox_warning"/>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783968264384" ID="ID_1390930082" MODIFIED="1783968803545" TEXT="das ist ausreichend um die Cross-Thread-Visibility sicherzustellen">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
aber man sollte konzeptionell zwischen der visibility mit dem Kernel und der Visibility zwischen den Workern unterscheiden; für ersteres gibt es die Barrieren in Liburing
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1783968339226" ID="ID_52764530" MODIFIED="1783968361355" TEXT="Blocken in der Grooming-Phase verhindern ⟶ sonst Engine-Stall">
|
||||||
|
<icon BUILTIN="clanbomber"/>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783968381176" ID="ID_291465589" MODIFIED="1783968803561" TEXT="Flow/Capacity-Steuerung ist essentiell notwendig">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
der Umstand daß neue IO-Aktivitäten gescheduled werden und Completions entnommen werden müssen, garantiert nur eine passive Backpressure (nicht entnommene Completions gehen nicht verloren, und der Platz in den URings ist begrenzt). Sehr wahrscheinlich ist mehr notwendig, damit die Engine rund läuft.
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783968535936" ID="ID_1390321079" MODIFIED="1783968546673" TEXT="Einordnung in gegenwärtige Trends">
|
||||||
|
<node CREATED="1783968547646" ID="ID_1203574703" MODIFIED="1783968635282" TEXT="Scheduler/Worker-Pattern wird standardisiert (C++26)">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
Es ist eine etablierte und bewährte Methode, und wird nicht weggehen. Was wir geschaffen haben konvergiert gut mit den allgemeinen Einsichten im Feld
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783968562254" ID="ID_1154684301" MODIFIED="1783968600700" TEXT="High-Performance-Computing: thread-per-core no shared data">
|
||||||
|
<richcontent TYPE="NOTE"><html>
|
||||||
|
<head/>
|
||||||
|
<body>
|
||||||
|
<p>
|
||||||
|
das ist ein Gegentrend, der aber auf einer anderen Größenordnung arbeitet (im Nanosekunden-Bereich)
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</html></richcontent>
|
||||||
|
</node>
|
||||||
|
<node CREATED="1783968636663" ID="ID_1048046164" MODIFIED="1783968651582" TEXT="sollte an sehr hohe Anzahl an Cores denken">
|
||||||
|
<icon BUILTIN="messagebox_warning"/>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
|
</node>
|
||||||
</node>
|
</node>
|
||||||
<node CREATED="1778113564544" ID="ID_1131259858" MODIFIED="1778113686162" TEXT="Integration IO-Buffer">
|
<node CREATED="1778113564544" ID="ID_1131259858" MODIFIED="1778113686162" TEXT="Integration IO-Buffer">
|
||||||
<linktarget COLOR="#4359d9" DESTINATION="ID_1131259858" ENDARROW="Default" ENDINCLINATION="-1448;-166;" ID="Arrow_ID_863939341" SOURCE="ID_688748631" STARTARROW="None" STARTINCLINATION="-1197;90;"/>
|
<linktarget COLOR="#4359d9" DESTINATION="ID_1131259858" ENDARROW="Default" ENDINCLINATION="-1448;-166;" ID="Arrow_ID_863939341" SOURCE="ID_688748631" STARTARROW="None" STARTINCLINATION="-1197;90;"/>
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue