BufferProvider: successfully complete the load test (see #1396)
With this third test case, a fairly continuous processing can be demonstrated, while also coordinating allocations in a decentralised way. The implementation behaves correct, and seemingly with satisfactory performance -- while there is certainly some room for improvement: with the processing pattern in this test, a nominal computation load of 4 seconds can be processed with 4 cores in ~ 1.3 seconds
This commit is contained in:
parent
fd0e62076a
commit
9461443e84
8 changed files with 256 additions and 118 deletions
|
|
@ -27,10 +27,12 @@
|
|||
**
|
||||
** @warning as of 2022 the implementation of `thread_local` in the GNU runtime
|
||||
** was observed to incur seemingly unnecessary overhead, which however
|
||||
** is relevant only in a high-performance environment.
|
||||
** @todo WIP-WIP 4/2026 prototyping an Engine Buffer manager /////////////////////////////////////////////TICKET #1425
|
||||
** is relevant only in a high-performance environment. However, some
|
||||
** [casual benchmarks](\ref LocalSlice_test::investigatePerformance)
|
||||
** indicated that the problem does not seem to be _that serious_...
|
||||
** @see LocalSlice_test
|
||||
** @see ////TODO usage example
|
||||
** @see LocalBufferStage (usage example)
|
||||
** @see buffer-provider-load-test.cpp
|
||||
**
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -88,6 +88,16 @@
|
|||
** implementation; when used from the actual [Render Environment](\ref render-environment.hpp),
|
||||
** this will be backed by a production-strenght and concurrency-safe implementation.
|
||||
**
|
||||
** \par Production-grade implementation
|
||||
** For use in the actual Render Engine, operation within a massively concurrent environment
|
||||
** must be taken into account. In spring 2026, a first prototype of such an implementation
|
||||
** setup was created, using a thread-local back-end for both the _Stage_ and _Store_ parts.
|
||||
** The actual allocations are managed by \ref EngineBufferManager and will be transported
|
||||
** to and from the \ref LocalMemPool in each thread through an asynchronous messaging queue.
|
||||
** The number of allocations to retain in those thread-local memory pools is coordinated
|
||||
** by a heuristic, based on an efficiency score maintained at each local entry.
|
||||
** @todo 2026 if this scheme is able to deliver adequate performance remains to be seen...
|
||||
**
|
||||
** \par Design critique
|
||||
** In its current shape, BufferProvider is both a rather large front-end facade,
|
||||
** while also containing some »code behind« to translate the API invocations into
|
||||
|
|
@ -110,6 +120,7 @@
|
|||
** @todo 2026 we might consider adding alignment information to the associated TypeHandler.
|
||||
**
|
||||
** @see buffer-provider-protocol-test.cpp
|
||||
** @see buffer-provider-load-test.cpp
|
||||
** @see output-slot.hpp
|
||||
** @see engine-ctx.hpp
|
||||
** @see proc-node.hpp
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
** are sent back and collected by the EngineBufferManager, which serves
|
||||
** thus as an background collector and manager for the buffer memory.
|
||||
**
|
||||
** @todo WIP-WIP 4/2026 The intention is to use a family of pools eventually,
|
||||
** @todo WIP 4/2026 The intention is to use a family of pools eventually,
|
||||
** with some of the most relevant tile sizes. The EngineBufferManager
|
||||
** would then actually retain ownership of all allocations and just
|
||||
** _lease_ them to the LocalMemPool instances. Allocations would be
|
||||
|
|
@ -44,33 +44,20 @@
|
|||
#include "lib/error.hpp"
|
||||
#include "lib/util-quant.hpp"
|
||||
#include "lib/allocator-handle.hpp"
|
||||
//#include "lib/hash-value.h"
|
||||
#include "vault/mem/engine-buffer-manager.hpp"
|
||||
//#include "vault/mem/type-handler.hpp"
|
||||
//#include "vault/mem/buffer-local-tag.hpp"
|
||||
#include "lib/nocopy.hpp"
|
||||
//#include "lib/util.hpp"
|
||||
|
||||
#include <memory>
|
||||
#include <array>
|
||||
|
||||
|
||||
namespace vault{
|
||||
namespace mem {
|
||||
|
||||
// using lib::HashVal;
|
||||
// using util::unConst;
|
||||
|
||||
#include <memory>
|
||||
#include <array>
|
||||
namespace err = lumiera::error;
|
||||
|
||||
using std::byte;
|
||||
|
||||
|
||||
namespace { // config and internal helpers...
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
/* === Setup of »naïve« buffer allocation === */
|
||||
|
||||
|
|
@ -137,10 +124,5 @@ namespace mem {
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
}} // namespace vault::mem
|
||||
#endif /*VAULT_MEM_ENGINE_BUFFER_ALLOCATOR_H*/
|
||||
|
|
|
|||
|
|
@ -17,10 +17,18 @@
|
|||
** a new heap block for any buffer, without deallocating memory ever. This allows to
|
||||
** attach additional tracking status flags for each allocated block and validate
|
||||
** allocator behaviour after the fact.
|
||||
** @remark for use in the actual Render Engine, a much more elaborate setup is necessary,
|
||||
** to avoid contention due to the centralised nature of memory allocation. In spring 2026,
|
||||
** an initial prototype was created, comprising
|
||||
** - LocalBufferStage
|
||||
** - LocalBufferStore
|
||||
** - EngineBufferManager
|
||||
** - EngineMetadata
|
||||
**
|
||||
** @see DiagnosticOutputSlot
|
||||
** @see DiagnosticBufferProvider
|
||||
** @see buffer-provider-protocol-test.cpp
|
||||
** @see buffer-provider-load-test.cpp
|
||||
** @see render-environment.cpp
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@
|
|||
|
||||
#include "test/run.hpp"
|
||||
#include "test/test-helper.hpp"
|
||||
#include "test/microbenchmark.hpp"
|
||||
#include "vault/mem/buffer-provider-setup.hpp"
|
||||
#include "vault/mem/engine-buffer-metadata.hpp"
|
||||
#include "vault/mem/engine-buffer-manager.hpp"
|
||||
|
|
@ -30,22 +31,16 @@
|
|||
#include "lib/sync-barrier.hpp"
|
||||
#include "lib/iter-stack.hpp"
|
||||
#include "lib/thread.hpp"
|
||||
//#include "lib/symbol.hpp"
|
||||
#include "lib/random.hpp"
|
||||
#include "test/diagnostic-output.hpp"////////////TODO
|
||||
|
||||
//#include <algorithm>
|
||||
//#include <string>
|
||||
#include <array>
|
||||
|
||||
using lib::Random;
|
||||
using lib::Depend;
|
||||
using lib::DependInject;
|
||||
using lib::explore;
|
||||
//using lib::Literal;
|
||||
using lib::Thread;
|
||||
using lib::SyncBarrier;
|
||||
using lib::ScopedCollection;
|
||||
using test::benchmarkTime;
|
||||
using vault::gear::test::ComputationalLoad;
|
||||
using std::this_thread::yield;
|
||||
using std::this_thread::sleep_for;
|
||||
|
|
@ -59,7 +54,8 @@ namespace test {
|
|||
|
||||
namespace { // ========== Test Setup ==========
|
||||
|
||||
const size_t MANY_THREADS = 100; ///< press concurrently
|
||||
const size_t MANY_THREADS = 100; ///< press concurrently
|
||||
const size_t FULL_LOAD_CORES = 4; ///< workers to use for a _full load run_
|
||||
const size_t MAX_SCALE = 5; ///< maximum scale step for randomised buffer types
|
||||
|
||||
|
||||
|
|
@ -158,7 +154,6 @@ namespace test {
|
|||
workActivity()
|
||||
{
|
||||
SyncBarrier::sync();
|
||||
cout<<"Start:"<<std::this_thread::get_id()<<endl;
|
||||
|
||||
for (uint i=0; i<CONF::NUM_JOBS; ++i)
|
||||
{
|
||||
|
|
@ -171,13 +166,15 @@ cout<<"Start:"<<std::this_thread::get_id()<<endl;
|
|||
|
||||
/**
|
||||
* Simulated calculation job.
|
||||
* A random-walk like memory load pattern is generated
|
||||
* by claiming and releasing a random number of buffers, picking one
|
||||
* A random-walk-like memory load pattern is generated
|
||||
* by claiming and releasing a random number of buffers, and picking one
|
||||
* of the preconfigured »buffer types« (size) randomly. The corresponding
|
||||
* BuffHandle(s) are passed through a queue; the head element from that queue
|
||||
* is used to generate a combined CPU and memory load in each step.
|
||||
* Deliberately, the pre-announced capacity does not exactly fit the generated
|
||||
* load, so that constant rebalancing between local and global pool is provoked.
|
||||
* @remark this test attempts to be _nasty_ — because the goal is to
|
||||
* demonstrate correct behaviour under pressure.
|
||||
*/
|
||||
void
|
||||
jobActivity()
|
||||
|
|
@ -211,9 +208,9 @@ cout<<"Start:"<<std::this_thread::get_id()<<endl;
|
|||
};
|
||||
|
||||
|
||||
//---Announce-guess-of-average-required-capacity-----------
|
||||
//---Announce-some-random-capacity-beforehand------
|
||||
for (BuffDescr& buffType : Ctx::buffType_)
|
||||
buffType.announce (util::ceilDiv (CONF::STEP_SPREAD, 2u));
|
||||
buffType.announce (rand_.i (CONF::STEP_SPREAD));
|
||||
|
||||
//---Process-sequence-of-work-steps-----
|
||||
for (uint i=0; i<CONF::JOB_STEPS; ++i)
|
||||
|
|
@ -255,7 +252,6 @@ cout<<"Start:"<<std::this_thread::get_id()<<endl;
|
|||
if (Ctx::buffType_.empty()
|
||||
or not isKnown (Ctx::buffType_[0]))
|
||||
{
|
||||
cout<<"init-types"<<endl;
|
||||
Ctx::buffType_.clear();
|
||||
Ctx::buffType_.populate_by(
|
||||
BuffTypes::invoke(
|
||||
|
|
@ -268,7 +264,6 @@ cout<<"init-types"<<endl;
|
|||
}
|
||||
if (Ctx::calibrated_ != load_.sizeBase)
|
||||
{
|
||||
cout<<"calibrate"<<endl;
|
||||
load_.calibrate();
|
||||
Ctx::calibrated_ = load_.sizeBase;
|
||||
}
|
||||
|
|
@ -294,7 +289,7 @@ cout<<"calibrate"<<endl;
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
/**************************************************************************//**
|
||||
* @test Integration test of the Render Engine buffer management subsystem.
|
||||
* - this test uses a setup and wiring of components similar to the
|
||||
|
|
@ -335,21 +330,16 @@ cout<<"calibrate"<<endl;
|
|||
while (worker)
|
||||
sleep_for (200us);
|
||||
|
||||
SHOW_EXPR("hurgha")
|
||||
SHOW_EXPR(bool(mockEngine.globalPool))
|
||||
SHOW_EXPR(bool(mockEngine.metaHub))
|
||||
// the central services were indeed requested / created
|
||||
CHECK (mockEngine.globalPool);
|
||||
CHECK (mockEngine.globalPool);
|
||||
CHECK (mockEngine.metaHub);
|
||||
|
||||
SHOW_EXPR(mockEngine.metaHub->cntEntries())
|
||||
// 5 distinct buffer types registered
|
||||
CHECK (5 == mockEngine.metaHub->cntEntries());
|
||||
|
||||
sleep_for (500us); // additional delay for the local pool's destructor
|
||||
// (which is invoked after the thread has terminated)
|
||||
|
||||
SHOW_EXPR(watch(*mockEngine.globalPool).numAllocs())
|
||||
// there must be some allocations, still sitting in the return queue
|
||||
CHECK (0 < watch(*mockEngine.globalPool).numAllocs());
|
||||
|
||||
|
|
@ -357,14 +347,13 @@ SHOW_EXPR(watch(*mockEngine.globalPool).numAllocs())
|
|||
// sent back by the local pool's destructor...
|
||||
mockEngine.globalPool->processPendingRequests();
|
||||
// now there should be no memory leaks.......
|
||||
SHOW_EXPR(watch(*mockEngine.globalPool).bytesLeased());
|
||||
CHECK (0 == watch(*mockEngine.globalPool).bytesLeased());
|
||||
}
|
||||
|
||||
|
||||
|
||||
/** @test
|
||||
*
|
||||
/** @test press the same setup using a
|
||||
* massive overload of concurrent workers
|
||||
*/
|
||||
void
|
||||
verify_massiveOverload()
|
||||
|
|
@ -379,24 +368,51 @@ SHOW_EXPR(watch(*mockEngine.globalPool).bytesLeased());
|
|||
while (explore(threads).has_any())
|
||||
sleep_for (5ms);
|
||||
|
||||
SHOW_EXPR("harumpfha")
|
||||
SHOW_EXPR(mockEngine.metaHub->cntEntries())
|
||||
SHOW_EXPR(watch(*mockEngine.globalPool).numAllocs())
|
||||
CHECK (mockEngine.globalPool);
|
||||
// again 5 distinct buffer types registered
|
||||
CHECK (5 == mockEngine.metaHub->cntEntries());
|
||||
CHECK (0 < watch(*mockEngine.globalPool).numAllocs());
|
||||
|
||||
sleep_for (500us);
|
||||
mockEngine.globalPool->processPendingRequests();
|
||||
SHOW_EXPR(watch(*mockEngine.globalPool).bytesLeased());
|
||||
|
||||
CHECK (0 == watch(*mockEngine.globalPool).bytesLeased());
|
||||
}
|
||||
|
||||
|
||||
|
||||
/** @test
|
||||
*
|
||||
/** worker configuration for seamless full load */
|
||||
struct FullLoadSetup : WorkSetup
|
||||
{
|
||||
static constexpr uint JOB_STEPS = 100; // number of processing steps in a single job
|
||||
static constexpr uint STEP_SPREAD = 2; // reduced irregularity of allocations
|
||||
static constexpr uint LOAD_SPREAD = 0; // effectively disable variation of buffer types
|
||||
static constexpr uint MAX_DELAY = 0; // also disable random sleep between jobs
|
||||
};
|
||||
|
||||
/** @test attempt to create a coordinated _full load_
|
||||
* - configure the workers to compute without pause
|
||||
* - use more repetitions in a single job
|
||||
* - configured load time should be 1000ms per thread
|
||||
* - use small number of workers; each gets its own core
|
||||
* - capture the overall run time of the workers
|
||||
* - coordination overhead should not be excessive
|
||||
*/
|
||||
void
|
||||
verify_controlledLoad()
|
||||
{
|
||||
Ctx mockEngine;
|
||||
using Threads = ScopedCollection<DummyWorkerThread<FullLoadSetup>>;
|
||||
|
||||
double time_us = benchmarkTime ([]{ // run a set of threads with full-load config...
|
||||
Threads threads{FULL_LOAD_CORES, Threads::fill()};
|
||||
while (explore(threads).has_any())
|
||||
sleep_for (1ms);
|
||||
});
|
||||
|
||||
CHECK (time_us < 1.6e6);
|
||||
sleep_for (500us);
|
||||
mockEngine.globalPool->processPendingRequests();
|
||||
CHECK (0 == watch(*mockEngine.globalPool).bytesLeased());
|
||||
}
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -71,6 +71,7 @@ namespace test {
|
|||
* for diagnostics and does not actually _manage_ buffers; rather each buffer
|
||||
* is allocated on the heap and never released, so that any allocation and
|
||||
* all buffer contents can be verified after the fact.
|
||||
* @see BufferProviderLoad_test for a production-grade setup.
|
||||
*/
|
||||
class BufferProviderProtocol_test : public Test
|
||||
{
|
||||
|
|
|
|||
|
|
@ -1206,29 +1206,41 @@ Please note the shortcomings and logical contradictions in the solution currentl
|
|||
* The current design rather places the implementation according to the roles of the involved entities, which causes some ping-pong on the implementation level. Especially the ScopeLocator singleton can be accessed multiple times. This is the usual clarity vs. performance tradeoff. Scope resolution is assumed rather to be //not performance critical.//
|
||||
</pre>
|
||||
</div>
|
||||
<div title="BuffHandle" modifier="Ichthyostega" created="201109021617" modified="201109232348" tags="Rendering spec draft">
|
||||
<div title="BuffHandle" modifier="Ichthyostega" created="201109021617" modified="202605300134" tags="Rendering spec draft" changecount="6">
|
||||
<pre>All rendering, transformations and output of media data requires using ''data buffers'' -- but the actual layout and handling of these buffers is closely related to the actual implementation of these operations. As we're relying heavily on external libraries and plug-ins for performing these operations, there is no hope getting away with just one single {{{Buffer}}} data type definition. Thus, we need to confine ourselves to a common denominator of basic operations regarding data buffers and abstract the access to these operations through a BufferProvider entity. Beyond these basic operations, mostly we just need to assure that //a buffer exists as an distinguishable element// -- which in practice boils down to pushing around {{{void*}}} variables.
|
||||
|
||||
Obviously, overloading a pointer with semantic meaning isn't exactly a brilliant idea -- and the usual answer is to embed this pointer into a smart handle, which also yields the nice side-effect of explaining this design to the reader. Thus a buffer handle
|
||||
Obviously, overloading a pointer with semantic meaning isn't exactly a brilliant idea -- and the usual answer is to embed this pointer into some wrapper or handle, which also yields the additional benefit of explaining this design to the reader. Thus a buffer handle
|
||||
* can only be obtained from a BufferProvider
|
||||
* can be used to identify a buffer
|
||||
* can be dereferenced
|
||||
* can be copied
|
||||
|
||||
!design quest: buffer type information
|
||||
To perform anything useful with such a buffer handle, the client code needs some additional information, which can be generalised into a //type information:// Either, the client needs to know the size and kind of data to expect in the buffer, maybe just assume to get a specific buffer with suitably dimensions, or the client needs to know which buffer provider to contact for any management operations on that buffer (handle). And, at some point there needs to be a mechanism to verify the validity of a handle. But all of this doesn't mean that it's necessary to encode or embedd this information directly into the handle -- it might also be stored into a registration table (which has the downside of creating contention), or it might just be attached implicitly to the invocation context.
|
||||
!A design challenge: buffer type information
|
||||
To perform anything useful with such a buffer handle, the client code needs some additional information, which can be generalised into a //type information:// Either, the client needs to know the size and kind of data to expect in the buffer, maybe just assume to get a specific buffer with suitably dimensions, or the client needs to know which buffer provider to contact for any management operations on that buffer (handle). And, at some point there needs to be a mechanism to verify the validity of a handle. But all of this doesn't mean that it's necessary to encode or embed this information directly into the handle -- it might also be stored into a registration table (which has the downside of creating contention), or it might just be attached directly or implicitly to the invocation context.
|
||||
|
||||
Just linking this type information to the context is certainly the most elegant solution, but also by far the most difficult to achieve -- not to mention the implicit dependency on a very specific invocation situation. So for now (9/2011) it seems best to stick to the simple and explicit implementation, just keeping that structural optimisation in mind. And the link to this buffer type information should be made explicit within the definition anyway, even if we choose to employ another design tradeoff later.
|
||||
* thus the conclusion is: we introduce a ''descriptor object'', which will be stored within the handle
|
||||
* each BufferProvider exposes a ''descriptor prototype''; it can be specialised and used by to [[organise implementation details|BufferMetadata]]
|
||||
Within the realm of the Render Engine, various different activities are finally translated into some function that accesses a block of memory. However, this common scheme is only the point of access, since different kinds of processing will require different handling patterns -- and there is the danger that varying requirements will leak into the basic structure of the render processing. An ever increasing complexity in this central region of the application is seen as an essential threat -- and so ''abstraction'' is seen as the primary goal of this design.
|
||||
* whenever //some kind of buffer// needs to be used, a ''handle'' is passed
|
||||
* this handle is only marked with a hash-ID and a backlink to some //managing service//
|
||||
* which in turn must be structured in such a way that //differing back-ends can be built// -- to serve the different use cases
|
||||
|
||||
The purpose of the Lumiera Render Engine is to coordinate the media processing -- but not to conduct the processing itself. Within the Render Node network, the different kinds of activities associated with „just a buffer“ can thus be translated into a ''buffer type''. For invoking and instructing render operations, this type remains opaque -- in accordance with the actual usage, this implied additional knowledge can even be separated into two different relations:
|
||||
* we introduce a ''descriptor'' that encodes the //properties// of the buffer, most notably its size, possibly also a handler function &rarr; BufferMetadata
|
||||
* yet we also include a link to a ''backing service'' -- which can be configured to suit the purpose of the processing
|
||||
** the standard case of a BufferProvider is, well, to provide buffers
|
||||
** yet, at various places in the Render Node network, these buffers are linked to a //frame cache//
|
||||
** furthermore, at the source side, buffers must be filled by file-I/O operations
|
||||
** while at the output side, buffers participate in a precisely timed protocol for media output.
|
||||
|
||||
!sanity checks
|
||||
there are only limited sanity checks, and they can be expected to be optimised away for production builds.
|
||||
Basically the client is responsible for sane buffer access.
|
||||
</pre>
|
||||
!!!performance considerations
|
||||
While the backing service remains opaque, it should be noted that accessing this service can be performance critical. Any »service« always carries some element of central management -- and accessing a central coordinator can be a dangerous task when operating within a highly concurrent environment. Careful consideration is necessary regarding the location of //state// embedded into such a service: as long as some call is just propagated through layers of API functions, the effects remain confined into the current call stack. At some point however, long-lived state must be accessed (otherwise the service would be devoid of any meaning).
|
||||
|
||||
At this point, a separation is introduced into the //local coordinator// (which is implemented as a thread-local object) and the //central hub// of the service. As far as possible, the communication with the latter should be implemented as ''asynchronous messaging''
|
||||
|
||||
!!!sanity checks
|
||||
There are only limited sanity checks, and they can be expected to be optimised away for production builds.
|
||||
The render processing is assumed to proceed along preconfigured processing pipelines, which are instantiated from a »blueprint« -- and the [[Builder]] is responsible to arrange this calculation prototype in such a way, that only valid data accesses are possible. The processing functions and the buffer descriptors are preconfigured to match up.</pre>
|
||||
</div>
|
||||
<div title="BufferManagement" modifier="Ichthyostega" created="201109151420" modified="202602150137" tags="Rendering Player spec draft" changecount="3">
|
||||
<div title="BufferManagement" modifier="Ichthyostega" created="201109151420" modified="202605300050" tags="Rendering Player spec draft" changecount="4">
|
||||
<pre>Buffers are used to hold the media data for processing and output. Within the Lumiera RenderEngine and [[Player]] subsystem, we use some common concepts to handle the access and allocation of working buffers. Yet this doesn't imply having only one central authority in charge of every buffer -- such an approach wouldn't be possible (due to collaboration with external systems) and wouldn't be desirable either. Rather, there are some common basic usage //patterns// -- and there are some core interfaces used throughout the organisation of the rendering process.
|
||||
|
||||
Mostly, the //client code,// i.e. code in need of using buffers, can access some BufferProvider, thereby delegating the actual buffer management. This binds the client to adhere to kind of a //buffer access protocol,// comprised of the ''announcing'', ''locking'', optionally ''attaching'' and finally the ''releasing'' steps. The actual implementation backing these operations is a matter of configuration, which will be setup as part of the ''build process'', when the Render Node network is created.
|
||||
|
|
@ -1243,7 +1255,7 @@ Mostly, the //client code,// i.e. code in need of using buffers, can access some
|
|||
|
||||
!primary implementations
|
||||
;memory pool
|
||||
:in all those situations, where we just need a working buffer for some time, a dedicated custom allocator will be used within the Render Engine. Access to this allocator from the actual worker threads is another, quite advanced topic, since we can not effort to contact a central manager component for each buffer access.
|
||||
:in all those situations, where we just need a working buffer for some time, a dedicated custom allocator will be used within the Render Engine. Access to this allocator from the actual worker threads is another, quite advanced topic, since we can not effort to contact a central manager component for each buffer access. Within each worker thread, a small //local allocation pool// is used, exchanging allocations with the central {{{EngineBufferManager}}} through lock-free queues.
|
||||
;frame cache
|
||||
:whenever a calculated result may be of further interest, beyond the immediate need triggering the calculation, it might be eligible for caching.
|
||||
:The Lumiera ''frame cache'' is a special BufferProvider, maintaining a larger pool of buffers which can be pinned and kept around for some time,
|
||||
|
|
@ -1271,8 +1283,8 @@ Beyond that, it can be necessary to associate at least a state flag with //indiv
|
|||
__Note__: while the API to access this service is uniform, conceptually there is a difference between just using the (shared) type information and associating individual metadata, like the buffer state. Type-~IDs, once allocated, will never be discarded (within the lifetime of an Lumiera application instance -- while buffer associations, and further individual metadata //will be discarded,// when releasing the corresponding buffer. According to the ''prototype pattern'', individual metadata is treated as a one-way-off specialisation.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="BufferProvider" modifier="Ichthyostega" created="201107082330" modified="202602150142" tags="Rendering spec draft" changecount="12">
|
||||
<pre>Analysis of requirement shows that direct access to the buffers holding actual media data is not necessary -- at leas within the entire implementation of the Render Nodes Network. This finding is based on the assumption, that Lumiera does not perform any media processing on its own; all processing is delegated to external libraries. When taking this approach, buffers can be reduced to just some entity to be //managed,// i.e. "allocated", "locked" and "released"; the //actual meaning of these operations can be left to the implementation.// So the code within the render engine just pushes around ''smart-ptr like handles''. These [[buffer handles|BuffHandle]] act as a front-end, being created by and are linked to a {{{BufferProvider}}} implementation. There is no need to manage the lifecycle of buffers automatically, because the use of buffers is embedded into the render calculation cycle, which follows a strict call scheme, which ensures that all buffers are provided before invoking an operation and that buffers are released afterwards. Buffer management can thus be reduced to the following primitive operations...
|
||||
<div title="BufferProvider" modifier="Ichthyostega" created="201107082330" modified="202605300055" tags="Rendering spec draft" changecount="14">
|
||||
<pre>In-depth analysis of requirements indicates that direct access to the buffers holding actual media data is not necessary -- at least //within the implementation// of the Render Nodes Network. This finding is based on the assumption that Lumiera does not perform any media processing on its own; all processing is delegated to external libraries. When taking this approach, buffers can be reduced to just some entity to be //managed,// i.e. "allocated", "locked" and "released"; the //actual meaning of these operations can be left to the implementation.// So access for the code within the render engine can be reduced to exchanging //light-weight handles//. These [[buffer handles|BuffHandle]] act as a front-end, being created by and are linked to a {{{BufferProvider}}} implementation. There is no need to manage the lifecycle of buffers automatically, because the use of buffers is embedded into the render calculation cycle, which follows a strict call scheme, which ensures that all buffers are provided before invoking an operation and that buffers are released afterwards. Buffer management can thus be reduced to the following primitive operations...
|
||||
* declaring the ''type'', i.e. the size of a buffer, and optionally an object to construct into the buffer storage
|
||||
* (optionally) an ''announcement'' that a given amount of buffers will be required soon
|
||||
* the next step is to ensure the necessary buffers are available, by obtaining (''locking'') a buffer handle
|
||||
|
|
|
|||
|
|
@ -143764,6 +143764,10 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1769303576693" ID="ID_399072135" MODIFIED="1770828085997" TEXT="die Implementierung ist nicht ausreichend auf Zustandsübergänge zentriert">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1780099972923" ID="ID_1019040694" MODIFIED="1780100051757" TEXT="eine neutralere Beurteilung wird erst viel später möglich sein">
|
||||
<arrowlink COLOR="#675e8f" DESTINATION="ID_186086868" ENDARROW="Default" ENDINCLINATION="-794;-26;" ID="Arrow_ID_1805633100" STARTARROW="None" STARTINCLINATION="-758;36;"/>
|
||||
<icon BUILTIN="hourglass"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1770828113207" ID="ID_1891198177" MODIFIED="1770828493362" TEXT="Konzeption der Fundemente">
|
||||
<linktarget COLOR="#f50221" DESTINATION="ID_1891198177" ENDARROW="Default" ENDINCLINATION="-700;-67;" ID="Arrow_ID_1175301159" SOURCE="ID_1154484414" STARTARROW="None" STARTINCLINATION="-1164;56;"/>
|
||||
|
|
@ -143863,7 +143867,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ede2a7" COLOR="#242380" CREATED="1778802024913" ID="ID_575451700" MODIFIED="1778802301707">
|
||||
<node BACKGROUND_COLOR="#ede2a7" COLOR="#242380" CREATED="1778802024913" ID="ID_575451700" MODIFIED="1780099939112">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -143876,7 +143880,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...wodurch die Worker-Threads diese Aufgabe probabilistisch mit erledigen: wannimmer ein Worker eine Allokation angefordert hat, diese aber noch nicht zugestellt wurde, macht er mit globalem Lock eine Runde der Allokations-Arbeit
|
||||
...wodurch die Worker-Threads diese Aufgabe probabilistisch mit erledigen: wann immer ein Worker eine Allokation angefordert hat, diese aber noch nicht zugestellt wurde, macht er mit globalem Lock eine Runde der Allokations-Arbeit
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
|
|
@ -144066,7 +144070,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1776195345475" ID="ID_773105612" MODIFIED="1776195351345" TEXT="Problem der Code-Struktur">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#370f69" CREATED="1776195345475" ID="ID_773105612" MODIFIED="1780099646308" TEXT="Problem der Code-Struktur">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1776195352772" ID="ID_865032756" MODIFIED="1776195928687">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
|
|
@ -144137,7 +144141,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1776196630096" ID="ID_1510075065" MODIFIED="1776196674318" TEXT="jedes Slice muß stets von Null-auf handlungsfähig sein"/>
|
||||
<node CREATED="1776196881798" ID="ID_1250147382" MODIFIED="1776196902243" TEXT="jedes Slice muß als eigenständige Instanz mit einer Zentrale kommunizieren können"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1776196927192" ID="ID_1790936937" MODIFIED="1776196934764" TEXT="Analyse: ist das möglich?">
|
||||
<node BACKGROUND_COLOR="#bab6c8" COLOR="#564398" CREATED="1776196927192" FOLDED="true" ID="ID_1790936937" MODIFIED="1780099570236" TEXT="Analyse: ist das möglich?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1776199263823" ID="ID_11659909" MODIFIED="1776199286039" TEXT="Store">
|
||||
<node CREATED="1776199287308" ID="ID_1968928582" MODIFIED="1776199292991" TEXT="erscheint einfach...."/>
|
||||
|
|
@ -146314,7 +146318,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1776814507533" ID="ID_189865287" MODIFIED="1776814576271" TEXT="Ownership / Transaktionelle Sicherheit">
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1776814507533" FOLDED="true" ID="ID_189865287" MODIFIED="1780099368869" TEXT="Ownership / Transaktionelle Sicherheit">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node BACKGROUND_COLOR="#d9b592" COLOR="#5a0f69" CREATED="1776816810560" ID="ID_1402352728" MODIFIED="1779578509948" TEXT="das System muß auch korrekt arbeiten, wenn ein Worker-Thread terminiert">
|
||||
<arrowlink COLOR="#e01436" DESTINATION="ID_609664480" ENDARROW="None" ENDINCLINATION="-1139;0;" ID="Arrow_ID_649333039" STARTARROW="Default" STARTINCLINATION="1057;40;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
|
|
@ -146359,7 +146364,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1776817873864" ID="ID_1964767554" MODIFIED="1778792259242" TEXT="Diskussion und Abwägung">
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1776817873864" FOLDED="true" ID="ID_1964767554" MODIFIED="1778792259242" TEXT="Diskussion und Abwägung">
|
||||
<linktarget COLOR="#651733" DESTINATION="ID_1964767554" ENDARROW="Default" ENDINCLINATION="-51;-1908;" ID="Arrow_ID_1601176637" SOURCE="ID_471365898" STARTARROW="None" STARTINCLINATION="-1556;58;"/>
|
||||
<node CREATED="1776817881283" ID="ID_1958629364" MODIFIED="1776817923320" TEXT="tatsächlich liegen die Modelle gar nicht so weit auseinander....">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -146621,7 +146626,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1776993954400" ID="ID_864271040" MODIFIED="1777317529563" TEXT="nochmal nachdenken!">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1776993967934" ID="ID_1550862400" MODIFIED="1776993981224" TEXT="ich sehe jetzt drei mögliche Lösungen">
|
||||
<node COLOR="#435e98" CREATED="1776993967934" FOLDED="true" ID="ID_1550862400" MODIFIED="1780099341634" TEXT="ich sehe jetzt drei mögliche Lösungen">
|
||||
<node CREATED="1776993982660" ID="ID_1304666636" MODIFIED="1776994204836" TEXT="alles neu implementieren">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
|
|
@ -146758,9 +146763,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1776818369490" ID="ID_1521404080" MODIFIED="1777317328349" TEXT="Konsequenzen und Aufgaben">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1776818377985" ID="ID_892319469" MODIFIED="1776819082287" TEXT="BufferMetadata">
|
||||
<node COLOR="#338800" CREATED="1776818369490" ID="ID_1521404080" MODIFIED="1780099505261" TEXT="Konsequenzen und Aufgaben">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1776818377985" FOLDED="true" ID="ID_892319469" MODIFIED="1780099616520" TEXT="BufferMetadata">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1777024713120" ID="ID_24309556" MODIFIED="1777024728172" TEXT="eigentlich keine Anpassung notwendig">
|
||||
<icon BUILTIN="idea"/>
|
||||
|
|
@ -146769,9 +146774,12 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1777024765911" ID="ID_596148209" MODIFIED="1777024771000" TEXT="Einträge stehen lassen"/>
|
||||
<node CREATED="1777024772191" ID="ID_645148091" MODIFIED="1777024802721" TEXT="erneute Allokation mit gleicher Adresse aus FREE-State zulassen"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#ab020b" CREATED="1780099294357" ID="ID_822626107" MODIFIED="1780099329523" TEXT="Vorsicht: durch die replizierte Datenhaltung wird Löschen von Einträgen problematisch">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1777050407430" ID="ID_1385383632" MODIFIED="1778800333726" TEXT="LocalMemPool">
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1777050407430" FOLDED="true" ID="ID_1385383632" MODIFIED="1780099614885" TEXT="LocalMemPool">
|
||||
<linktarget COLOR="#357fd6" DESTINATION="ID_1385383632" ENDARROW="Default" ENDINCLINATION="-1147;-1723;" ID="Arrow_ID_997338547" SOURCE="ID_1140947088" STARTARROW="None" STARTINCLINATION="-513;25;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1777050440887" ID="ID_1006627416" MODIFIED="1777066692859" TEXT="Verhalten spezifizieren">
|
||||
|
|
@ -146811,7 +146819,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node COLOR="#338800" CREATED="1777052048904" ID="ID_1403107789" MODIFIED="1777084853433" TEXT="die Eingangs-Queue wird komplett (transparent) integriert">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1777078419796" ID="ID_1966959598" MODIFIED="1777084265167" TEXT="verwende boost::lockfree::queue"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#470f69" CREATED="1777078428098" ID="ID_1939142827" MODIFIED="1777084838373" TEXT="ist das die richtige Wahl?">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#470f69" CREATED="1777078428098" FOLDED="true" ID="ID_1939142827" MODIFIED="1780099279101" TEXT="ist das die richtige Wahl?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1777078440070" ID="ID_885005752" MODIFIED="1777078470502" TEXT="verlangt »trivial assignment« und Destructor"/>
|
||||
<node CREATED="1777078471365" ID="ID_769328039" MODIFIED="1777078487222" TEXT="heißt im Klartext: darf keine default-Initialiser haben">
|
||||
|
|
@ -146854,12 +146862,13 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="stop-sign"/>
|
||||
<node COLOR="#338800" CREATED="1777074497539" ID="ID_1587444173" MODIFIED="1777084232736" TEXT="sollte eine std::list verwenden (double-linked)">
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node CREATED="1777074521660" ID="ID_1763982951" MODIFIED="1777074532534" TEXT="grundsätzlich: gehe von einer kleinen Anzahl an Einträgen aus"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1777159795008" ID="ID_851031995" MODIFIED="1777317278947" TEXT="Heuristik zum Aufräumen schaffen">
|
||||
<node COLOR="#338800" CREATED="1777159795008" FOLDED="true" ID="ID_851031995" MODIFIED="1780099251457" TEXT="Heuristik zum Aufräumen schaffen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1777160636295" ID="ID_1174478817" MODIFIED="1777160642510" TEXT="gewünschter Effekt">
|
||||
<node CREATED="1777160710978" ID="ID_393248452" MODIFIED="1777160729106" TEXT="möglichst wenige und möglichst gut passende Buffer lokal halten"/>
|
||||
|
|
@ -146912,9 +146921,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1777164514849" ID="ID_489761092" MODIFIED="1777164525297" TEXT="und gewählt wird nach maximalem selectionScore"/>
|
||||
<node CREATED="1777164528024" ID="ID_1047876896" MODIFIED="1777164541639" TEXT="dieser gewählte Buffer bekommt dann einen Score-Update"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1779664650625" ID="ID_1141255727" MODIFIED="1779729238478" TEXT="Dazu einen 2.Layer ⟹ Heuristik zum Triggern">
|
||||
<node COLOR="#338800" CREATED="1779664650625" ID="ID_1141255727" MODIFIED="1780099246071" TEXT="Dazu einen 2.Layer ⟹ Heuristik zum Triggern">
|
||||
<linktarget COLOR="#4d5f6c" DESTINATION="ID_1141255727" ENDARROW="Default" ENDINCLINATION="-376;22;" ID="Arrow_ID_514664149" SOURCE="ID_1129342480" STARTARROW="None" STARTINCLINATION="-76;-210;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1779664722365" ID="ID_1461846299" MODIFIED="1779724531120" TEXT="im Kontext vom LocalBufferStore : erweiterte Heuristik skizziert">
|
||||
<arrowlink COLOR="#4f65bc" DESTINATION="ID_78533321" ENDARROW="Default" ENDINCLINATION="-548;697;" ID="Arrow_ID_1519732497" STARTARROW="Default" STARTINCLINATION="345;16;"/>
|
||||
<font NAME="SansSerif" SIZE="12"/>
|
||||
|
|
@ -146972,7 +146981,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</html></richcontent>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1777206798288" ID="ID_226587276" MODIFIED="1777230690484" TEXT="mögliche Ansätze">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1777206798288" FOLDED="true" ID="ID_226587276" MODIFIED="1780099240162" TEXT="mögliche Ansätze">
|
||||
<icon BUILTIN="edit"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1777206894812" ID="ID_1484542373" MODIFIED="1777206896343" TEXT="Pass-1 gute Matches"/>
|
||||
|
|
@ -147038,7 +147047,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<arrowlink COLOR="#f2ddc1" DESTINATION="ID_1195705832" ENDARROW="Default" ENDINCLINATION="16;47;" ID="Arrow_ID_296050493" STARTARROW="None" STARTINCLINATION="85;12;"/>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1778969102656" ID="ID_1242239297" MODIFIED="1779762145111" TEXT="verify_heuristic">
|
||||
<node COLOR="#338800" CREATED="1778969102656" FOLDED="true" ID="ID_1242239297" MODIFIED="1780099212263" TEXT="verify_heuristic">
|
||||
<linktarget COLOR="#333263" DESTINATION="ID_1242239297" ENDARROW="Default" ENDINCLINATION="-1163;-399;" ID="Arrow_ID_1851213418" SOURCE="ID_453821075" STARTARROW="None" STARTINCLINATION="-413;30;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1778979230293" ID="ID_1129342480" MODIFIED="1779664866045" TEXT="meine Idee der Heuristik umsetzen">
|
||||
|
|
@ -147094,7 +147103,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#a4c8cf" COLOR="#22695a" CREATED="1776819109351" ID="ID_1998897998" MODIFIED="1779579198844" TEXT="EngineBufferManager">
|
||||
<node BACKGROUND_COLOR="#a4c8cf" COLOR="#22695a" CREATED="1776819109351" FOLDED="true" ID="ID_1998897998" MODIFIED="1779579198844" TEXT="EngineBufferManager">
|
||||
<linktarget COLOR="#2270cc" DESTINATION="ID_1998897998" ENDARROW="Default" ENDINCLINATION="389;-2271;" ID="Arrow_ID_58701695" SOURCE="ID_853514765" STARTARROW="None" STARTINCLINATION="-1483;82;"/>
|
||||
<linktarget COLOR="#1b1ac0" DESTINATION="ID_1998897998" ENDARROW="Default" ENDINCLINATION="15;-85;" ID="Arrow_ID_1964764365" SOURCE="ID_1791813360" STARTARROW="None" STARTINCLINATION="-438;24;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
|
|
@ -147681,7 +147690,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1776819169143" ID="ID_1367745941" MODIFIED="1778694413443" TEXT="Schnittstelle für asynchrones Messaging bedenken">
|
||||
<node COLOR="#338800" CREATED="1776819169143" FOLDED="true" ID="ID_1367745941" MODIFIED="1778694413443" TEXT="Schnittstelle für asynchrones Messaging bedenken">
|
||||
<arrowlink COLOR="#fefab1" DESTINATION="ID_1503539674" ENDARROW="Default" ENDINCLINATION="-233;10;" ID="Arrow_ID_451160831" STARTARROW="None" STARTINCLINATION="92;5;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1778593688734" HGAP="35" ID="ID_730263664" MODIFIED="1778593713957" TEXT="Kern: die Verarbeitungs-Funktionalität" VSHIFT="-9">
|
||||
|
|
@ -147858,8 +147867,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1777324494396" ID="ID_23718162" MODIFIED="1777324511253" TEXT="möglicherweise ist eine dynamische Steuerung notwendig + fall-Back auf den Heap-Allokator"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1778507655159" ID="ID_662701381" MODIFIED="1778507661951" TEXT="Setup und Lebenszyklus">
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1778507655159" FOLDED="true" ID="ID_662701381" MODIFIED="1780099423027" TEXT="Setup und Lebenszyklus">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1778507710093" ID="ID_86258163" MODIFIED="1778507821841" TEXT="jemand muß die Instanz erzeugen">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1778507726771" ID="ID_1303340175" MODIFIED="1778507800975" TEXT="Notwendig sofern irgend etwas konfitguriert und verdrahtet werden soll">
|
||||
|
|
@ -147943,7 +147953,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1778507847611" ID="ID_1394284825" MODIFIED="1779328009963" TEXT="Race wegen terminierendem Thread">
|
||||
<node BACKGROUND_COLOR="#e6cfb0" COLOR="#a50125" CREATED="1778507847611" ID="ID_1394284825" MODIFIED="1780099405364" TEXT="Race wegen terminierendem Thread">
|
||||
<arrowlink COLOR="#ff1b15" DESTINATION="ID_931645192" ENDARROW="Default" ENDINCLINATION="-937;191;" ID="Arrow_ID_801625969" STARTARROW="None" STARTINCLINATION="171;-11;"/>
|
||||
<icon BUILTIN="clanbomber"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1779327845116" HGAP="31" ID="ID_1344328276" MODIFIED="1779327990693" TEXT="konnte den Race nur mit Restrisiko abdichten..." VSHIFT="23">
|
||||
|
|
@ -148014,7 +148024,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node COLOR="#338800" CREATED="1778595475430" ID="ID_992537338" MODIFIED="1778635094590" TEXT="Diagnose-Zugang schaffen: watch(manager)">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1778599970816" ID="ID_346337478" MODIFIED="1778635102267" TEXT="verify_syncRequest">
|
||||
<node COLOR="#338800" CREATED="1778599970816" FOLDED="true" ID="ID_346337478" MODIFIED="1780099427490" TEXT="verify_syncRequest">
|
||||
<node CREATED="1778599985224" ID="ID_1402142899" MODIFIED="1778599992550" TEXT="eine Allokation machen"/>
|
||||
<node CREATED="1778599993498" ID="ID_1315033221" MODIFIED="1778600012854" TEXT="Diagnose der belegten Bytes checken"/>
|
||||
<node CREATED="1778600013692" ID="ID_245317435" MODIFIED="1778600031040" TEXT="was in den Speicher schreiben">
|
||||
|
|
@ -148041,7 +148051,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1778635075937" ID="ID_1005055901" MODIFIED="1778635080660" TEXT="alles wieder freigeben"/>
|
||||
<node CREATED="1778635083791" ID="ID_227876159" MODIFIED="1778635088455" TEXT="Diagnostik prüfen"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1778599975152" ID="ID_1790536650" MODIFIED="1778788462054" TEXT="verify_asyncRequest">
|
||||
<node COLOR="#338800" CREATED="1778599975152" FOLDED="true" ID="ID_1790536650" MODIFIED="1780099429043" TEXT="verify_asyncRequest">
|
||||
<node CREATED="1778641426736" ID="ID_460139955" MODIFIED="1778641441187" TEXT="sollte hier gleich etwas »massives« machen"/>
|
||||
<node CREATED="1778641442270" ID="ID_1826595532" MODIFIED="1778641456169" TEXT="führe eine typische usage-sequence in jedem Thread aus">
|
||||
<node CREATED="1778641462236" ID="ID_51963277" MODIFIED="1778641469666" TEXT="fordere eine Allokation"/>
|
||||
|
|
@ -148357,8 +148367,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1779807848109" ID="ID_1050489006" MODIFIED="1780020337157" TEXT="Zusammenspiel aller Komponenten">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#338800" CREATED="1779807848109" FOLDED="true" ID="ID_1050489006" MODIFIED="1780099622207" TEXT="Zusammenspiel aller Komponenten">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1779811658144" ID="ID_48160877" MODIFIED="1779811912507" TEXT="Beschluß: einen Lasttest machen...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
|
|
@ -148406,11 +148416,11 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node COLOR="#338800" CREATED="1779839354828" ID="ID_518513597" MODIFIED="1780020400282" TEXT="Test-Worker">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1779839360162" ID="ID_328313949" MODIFIED="1779839367916" TEXT="muß sich in einem Thread betreiben lassen">
|
||||
<node CREATED="1779839360162" FOLDED="true" ID="ID_328313949" MODIFIED="1780099163836" TEXT="muß sich in einem Thread betreiben lassen">
|
||||
<node CREATED="1779839374568" ID="ID_583136761" MODIFIED="1779839386715" TEXT="idealerweise default-konstruiert"/>
|
||||
<node CREATED="1779839387637" ID="ID_15747866" MODIFIED="1779839400817" TEXT="muß eine eigene RandomGen-Instanz verwenden"/>
|
||||
</node>
|
||||
<node CREATED="1779839406426" ID="ID_938874821" MODIFIED="1779839430240" TEXT="sollte ein Repetitions-Muster ausführen">
|
||||
<node CREATED="1779839406426" FOLDED="true" ID="ID_938874821" MODIFIED="1780099159045" TEXT="sollte ein Repetitions-Muster ausführen">
|
||||
<node CREATED="1779839432034" ID="ID_36959428" MODIFIED="1779839458946" TEXT="sollte das Ausführen mehrerer Jobs hintereinander in einem Worker emulieren"/>
|
||||
<node CREATED="1779839464064" ID="ID_1404791709" MODIFIED="1779839736804" TEXT="zwischen den Arbeits-Blöcken sollte eine konfigurierbare Schlaf-Pause liegen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -148423,7 +148433,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1779839738171" ID="ID_826633055" MODIFIED="1779839753017" TEXT="die Arbeits-Blöcke">
|
||||
<node CREATED="1779839738171" FOLDED="true" ID="ID_826633055" MODIFIED="1780099155740" TEXT="die Arbeits-Blöcke....">
|
||||
<node CREATED="1779839754672" ID="ID_653852637" MODIFIED="1779839775894" TEXT="müssen mehrfach eine unregelmäßige Speicherlast erzeugen"/>
|
||||
<node CREATED="1779839817085" ID="ID_963086421" MODIFIED="1779839826640" TEXT="das könnte ein random-Walk sein">
|
||||
<node CREATED="1779839833907" ID="ID_299250287" MODIFIED="1779839844366" TEXT="für die Zahl der Allokationen / Deallokationen"/>
|
||||
|
|
@ -148517,7 +148527,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1779839960562" ID="ID_1753843907" MODIFIED="1779840001751" TEXT="dieser Testworker sollte für alle verschiedenen Test-Szenarien verwendbar sein">
|
||||
<node COLOR="#435e98" CREATED="1779839960562" FOLDED="true" ID="ID_1753843907" MODIFIED="1780099138316" TEXT="dieser Testworker sollte für alle verschiedenen Test-Szenarien verwendbar sein">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1779842388022" ID="ID_920297873" MODIFIED="1779842397154" TEXT="Varianten">
|
||||
<node CREATED="1779842408499" ID="ID_1477831827" MODIFIED="1779842424412" TEXT="mit/ohne Pausen zwischen den Arbeits-Blöcken"/>
|
||||
<node CREATED="1779842705255" ID="ID_580582504" MODIFIED="1779842719147" TEXT="den BufferProvider überhaupt nicht verwenden"/>
|
||||
|
|
@ -148532,7 +148543,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1779842883659" ID="ID_1608712431" MODIFIED="1779842890011" TEXT="Dimension der ComutationalLoad"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1779844131758" ID="ID_1023337515" MODIFIED="1779844139684" TEXT="Relevanz für die Testziele?">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#510f69" CREATED="1779844131758" ID="ID_1023337515" MODIFIED="1780099179426" TEXT="Relevanz für die Testziele?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1779844141250" ID="ID_1078777958" MODIFIED="1779844167168" TEXT="zur Erinnerung: es geht nur um Korrektheit — nicht um quantitative Messung"/>
|
||||
<node CREATED="1779844170153" ID="ID_1952885501" MODIFIED="1779844355676" TEXT="ABER die Fallabdeckung ist relevant für die Prüftiefe">
|
||||
|
|
@ -148556,7 +148567,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1779896309364" ID="ID_585456943" MODIFIED="1780020269167" TEXT="Implementierung">
|
||||
<node COLOR="#338800" CREATED="1779896309364" FOLDED="true" ID="ID_585456943" MODIFIED="1780099121889" TEXT="Implementierung">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1779896314395" ID="ID_808195038" MODIFIED="1779896326428" TEXT="Policy-based Design mit einem Setup-Record">
|
||||
<node CREATED="1779896334691" ID="ID_830197460" MODIFIED="1779896350540" TEXT="vor allem damit die Parameter im Test selber klar benannt sind"/>
|
||||
|
|
@ -148842,14 +148853,14 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1780020283668" ID="ID_475125993" MODIFIED="1780020384893" TEXT="Testfälle">
|
||||
<node COLOR="#338800" CREATED="1780020283668" ID="ID_475125993" MODIFIED="1780099079659" TEXT="Testfälle">
|
||||
<linktarget COLOR="#4587d6" DESTINATION="ID_475125993" ENDARROW="Default" ENDINCLINATION="-174;35;" ID="Arrow_ID_1000436933" SOURCE="ID_200114754" STARTARROW="None" STARTINCLINATION="93;10;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1780020287468" ID="ID_1223809546" MODIFIED="1780020317672" TEXT="Test-Worker single-threaded beobachtet">
|
||||
<arrowlink COLOR="#2413bd" DESTINATION="ID_741681228" ENDARROW="Default" ENDINCLINATION="-43;77;" ID="Arrow_ID_1505722901" STARTARROW="None" STARTINCLINATION="166;11;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1780060686656" ID="ID_1839375531" MODIFIED="1780072490179" TEXT="massiv pressen mit vielen Threads">
|
||||
<node COLOR="#338800" CREATED="1780060686656" FOLDED="true" ID="ID_1839375531" MODIFIED="1780099456780" TEXT="massiv pressen mit vielen Threads">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1780060737800" ID="ID_1373121543" MODIFIED="1780060779999" TEXT="das gleiche Setup — jetzt eine ScopedCollection der Threads">
|
||||
<icon BUILTIN="idea"/>
|
||||
|
|
@ -148860,15 +148871,16 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node BACKGROUND_COLOR="#adddc4" COLOR="#435e98" CREATED="1780060787082" ID="ID_1615088563" MODIFIED="1780060897085" TEXT="gut: terminiert sauber, ohne Speicherlecks">
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780060842619" ID="ID_322729434" MODIFIED="1780072470533" TEXT="bedenklich: nur 33% Last und dauert ewig">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780060842619" FOLDED="true" ID="ID_322729434" MODIFIED="1780099109352" TEXT="bedenklich: nur 33% Last und dauert ewig">
|
||||
<icon BUILTIN="smiley-oh"/>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1780061882332" ID="ID_626403939" MODIFIED="1780061941839" TEXT="okok ... offensichtlicher Fehler"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780061893706" ID="ID_1709176021" MODIFIED="1780061944989" TEXT="die Trigger-Bedingung für die Kalibrierung war falsch">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
<node CREATED="1780061907953" ID="ID_908839538" MODIFIED="1780061930093" TEXT="d.h. wir haben fast die ganze Zeit kalibriert und praktisch nicht concurent gearbeitet"/>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1780061953369" ID="ID_773467214" MODIFIED="1780072470532" TEXT="Assertion-Fail: mehrere Threads senden einen size-Request 0">
|
||||
<node COLOR="#435e98" CREATED="1780061953369" FOLDED="true" ID="ID_773467214" MODIFIED="1780099094311" TEXT="Assertion-Fail: mehrere Threads senden einen size-Request 0">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1780062937804" ID="ID_529419900" MODIFIED="1780062966300" TEXT="das muß vom announce() kommen"/>
|
||||
<node CREATED="1780063011162" ID="ID_1132794490" MODIFIED="1780063025636" TEXT="es sind sofort die ersten Announcements von jedem Thread"/>
|
||||
|
|
@ -148908,8 +148920,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
etwas anderes <i>ist an der Stelle auch relativ unwahrscheinlich:</i> die BASE_BUFFSIZ steckt ja eben grade statisch in der jeweilgen Thread-Klasse. Das würde nur abweichen, wenn man im gleichen Testfall mit mehreren verschiedenen Thread-Klassen operiert
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#93064b" CREATED="1780065580520" ID="ID_1314933188" MODIFIED="1780066858279" TEXT="Ha! da ist wohl doch noch ein weiterer Bug versteckt...">
|
||||
<icon BUILTIN="smiley-oh"/>
|
||||
</node>
|
||||
|
|
@ -148921,8 +148932,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
lookup liefert <b>nicht</b> Key::INVALID
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1780064640040" ID="ID_1881464215" MODIFIED="1780064655446" TEXT="nur die Kalibrierung kann man so eigentlich nicht feststellen">
|
||||
|
|
@ -148941,7 +148951,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1780067514967" ID="ID_504824325" MODIFIED="1780067537524" TEXT="Problem in der Test-Logik (vielleicht noch mehr?)">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780067514967" ID="ID_504824325" MODIFIED="1780099090974" TEXT="Problem in der Test-Logik (vielleicht noch mehr?)">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1780067539952" ID="ID_1338317341" MODIFIED="1780067565148" TEXT="die lokale Metadata-Registry vom Main-Thread kennt die Buffer-Typen noch"/>
|
||||
<node CREATED="1780067600867" ID="ID_57805001" MODIFIED="1780067628179" TEXT="deshalb greift die (überarbeitete) Trigger-Bedingung nicht beim Thread-Start"/>
|
||||
|
|
@ -149018,8 +149028,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1780072494794" ID="ID_1052771449" MODIFIED="1780072502590" TEXT="gezielte saubere Vollast">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node COLOR="#338800" CREATED="1780072494794" FOLDED="true" ID="ID_1052771449" MODIFIED="1780099459208" TEXT="gezielte saubere Vollast">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#b00f54" CREATED="1780072509452" ID="ID_1373816448" MODIFIED="1780072598144" TEXT="sollte dann endgültig nur mit 4 Threads laufen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
|
|
@ -149031,9 +149041,85 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</html></richcontent>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node CREATED="1780072605183" ID="ID_95023696" MODIFIED="1780072611554" TEXT="spezielle Konfiguration">
|
||||
<node COLOR="#435e98" CREATED="1780072605183" ID="ID_95023696" MODIFIED="1780098111540" TEXT="spezielle Konfiguration">
|
||||
<node CREATED="1780072613110" ID="ID_1162990013" MODIFIED="1780072682240" TEXT="kein pre-delay — jeder Thread soll »heiß« laufen"/>
|
||||
<node CREATED="1780072646666" ID="ID_111344849" MODIFIED="1780072662739" TEXT="scaleStep auf 1 begrenzen ⟹ vorhersagbare Laufzeit"/>
|
||||
<node CREATED="1780097442905" ID="ID_425445730" MODIFIED="1780097455784" TEXT="nur minimale Variation der Allokationen/Deallokationen"/>
|
||||
<node CREATED="1780097463831" ID="ID_376482016" MODIFIED="1780097479017" TEXT="mehr Schritte im Job: 100 statt 10">
|
||||
<node CREATED="1780098015244" ID="ID_135741454" MODIFIED="1780098064547" TEXT="die Annoucements sorgen deutlich für zusätzliche Last">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
wird ersichtlich, wenn man die Verteilung auf Jobs bei gleicher Gesamtzahl variiert
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1780098086490" ID="ID_906751866" MODIFIED="1780098114790" TEXT="Laufzeit der Worker-Threads messen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#434798" CREATED="1780098116221" ID="ID_484624436" MODIFIED="1780098820124" TEXT="Beobachtungen">
|
||||
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="forward"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#a906a6" CREATED="1780098127304" ID="ID_507636841" MODIFIED="1780098147726" TEXT="nich so dolle">
|
||||
<icon BUILTIN="smiley-neutral"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e3b79c" COLOR="#690f14" CREATED="1780098198840" ID="ID_755929474" MODIFIED="1780098230152" TEXT="in der Standard-Konfiguration kommt Faktor 2.5 raus">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1780098249148" ID="ID_711448005" MODIFIED="1780098270168" TEXT="wenn die Threads insgesamt länger laufen, wird's deutlich besser">
|
||||
<icon BUILTIN="smiley-oh"/>
|
||||
</node>
|
||||
<node CREATED="1780098307618" ID="ID_1949307861" MODIFIED="1780098530986" TEXT="nicht alle Cores verwenden ⟹ Zeit sinkt von 1.6sec auf 1.3sec">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...was darauf hindeutet, daß <i>sonstige Aktivitäten</i> hier erheblich störend wirken. So z.B. das regelmäßige Polling vom Main-Thread (was im Debug-Mode auch relativ aufwendig ist, weil ich iterExplorer verwende).
|
||||
</p>
|
||||
<p>
|
||||
Zudem laufen mehrere Monster auf meinem Rechner, die allesamt einen Threadpool haben und auch normalerweise keine Ruhe geben (Firefox, Thunderbird, Eclipse, GTK/XFCE)
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1780098534684" ID="ID_1114713478" MODIFIED="1780099063889">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
es ist aber <i>überhaupt nicht klar</i> wo der Overhead herkommt
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#6d5a82" DESTINATION="ID_1114713478" ENDARROW="Default" ENDINCLINATION="-16;179;" ID="Arrow_ID_1991911025" SOURCE="ID_1355000856" STARTARROW="None" STARTINCLINATION="258;10;"/>
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1780098564251" ID="ID_1883425778" MODIFIED="1780098584352" TEXT="ich kann nur die erwartete/kalibrierte Verzögerung als Bezugspunkt nehmen"/>
|
||||
<node CREATED="1780098585333" ID="ID_1448082727" MODIFIED="1780098606341" TEXT="es ist ziemlich wahrscheinlich, daß die ComputationalLoad durch Störungen langsamer wird"/>
|
||||
<node CREATED="1780098856857" ID="ID_159621226" MODIFIED="1780098961283" TEXT="zudem läßt sich überhaupt nicht abschätzen, wie viel Kommunikation/Allokation es gab">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...bedingt durch die Randomisierung, kann es nämlich durchaus sein, daß eine gewisse Teil-Kapazität permanent hin- und herschwappt; diese würde aktuell dann jeweils de-alloziert und kurz darauf wieder neu alloziert.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1780098609569" ID="ID_1849632026" MODIFIED="1780098789757" TEXT="man müßte also eine detailierte Performance-Analyse machen (⟹ IncidenceCount verwenden)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...leider würde das eine spezielle Instrumentierung des Test-Subjects voraussetzen, und vermutlich auch eine genauere Steuerung des Verhaltens (die Randomisierung macht die Verhältnisse schwer abschätzbar). Erst damit ließe sich entscheiden, <i>wie viel zusätzliche Zeit denn tatsächlich verbraucht wird.</i>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -149044,10 +149130,18 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1779806981481" ID="ID_339298449" MODIFIED="1779807068096" TEXT="Integration und Tests">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1779811803748" ID="ID_1356647567" MODIFIED="1779811814407" TEXT="Tests">
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1779811854629" ID="ID_200114754" MODIFIED="1780020384893" TEXT="BufferProviderLoad_test">
|
||||
<node COLOR="#1f5672" CREATED="1779811854629" ID="ID_200114754" MODIFIED="1780099481123" TEXT="BufferProviderLoad_test">
|
||||
<arrowlink COLOR="#4587d6" DESTINATION="ID_475125993" ENDARROW="Default" ENDINCLINATION="-174;35;" ID="Arrow_ID_1000436933" STARTARROW="None" STARTINCLINATION="93;10;"/>
|
||||
<linktarget COLOR="#6b414a" DESTINATION="ID_200114754" ENDARROW="Default" ENDINCLINATION="74;-150;" ID="Arrow_ID_961812501" SOURCE="ID_48160877" STARTARROW="Default" STARTINCLINATION="-330;-11;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1780098989758" HGAP="47" ID="ID_767803243" MODIFIED="1780099004035" TEXT="Zwischenergebnisse..." VSHIFT="11">
|
||||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1780099005216" ID="ID_1294571105" MODIFIED="1780099020869" TEXT="das Gesamtsystem verhält sich korrekt, auch unter Druck"/>
|
||||
<node CREATED="1780099035213" ID="ID_1355000856" MODIFIED="1780099878662" TEXT="erheblicher Koordinations-Oberhead ist zu befürchten (aber nicht belegt)">
|
||||
<arrowlink COLOR="#6d5a82" DESTINATION="ID_1114713478" ENDARROW="Default" ENDINCLINATION="-16;179;" ID="Arrow_ID_1991911025" STARTARROW="None" STARTINCLINATION="258;10;"/>
|
||||
<linktarget COLOR="#8c8696" DESTINATION="ID_1355000856" ENDARROW="Default" ENDINCLINATION="8;124;" ID="Arrow_ID_1951616615" SOURCE="ID_1283287015" STARTARROW="None" STARTINCLINATION="167;5;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -149067,7 +149161,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
||||
<icon BUILTIN="forward"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1776820446435" ID="ID_186086868" MODIFIED="1776820472657" TEXT="Ich weiß: eine empirsche Überprüfung ist schwer — und liegt JAHRE in der Zukunft">
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1776820446435" ID="ID_186086868" MODIFIED="1780100051757" TEXT="Ich weiß: eine empirsche Überprüfung ist schwer — und liegt JAHRE in der Zukunft">
|
||||
<linktarget COLOR="#675e8f" DESTINATION="ID_186086868" ENDARROW="Default" ENDINCLINATION="-794;-26;" ID="Arrow_ID_1805633100" SOURCE="ID_1019040694" STARTARROW="None" STARTINCLINATION="-758;36;"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1776820478727" ID="ID_1441494881" MODIFIED="1776820524756">
|
||||
|
|
@ -149085,6 +149180,17 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1776820816987" ID="ID_1627919962" MODIFIED="1776820877607" TEXT="was mich dazu zwingt, mir architektonisch den rechten Spielraum für die Zukunft zu schaffen">
|
||||
<icon BUILTIN="forward"/>
|
||||
</node>
|
||||
<node CREATED="1780099676574" ID="ID_1283287015" MODIFIED="1780099878661" TEXT="Risiko: das Gesamtsystem wird sofort ziemlich komplex — und bringt nur mäßige Performance">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...dabei muß aber <b>nochmal betont</b> werden, daß es keinerlei Bezugspunkt gibt, denn ich habe nicht »naiv« angefangen; es könnte nämlich durchaus sein, daß sich eine naive Implementierung noch viel schlechter schlägt, und dann schwer zu verbessern ist — es könnte aber auch sein, daß dieses System irrsinnig overengineered ist, und letztlich nicht gut auf Performance getuned werden kann
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#8c8696" DESTINATION="ID_1355000856" ENDARROW="Default" ENDINCLINATION="8;124;" ID="Arrow_ID_1951616615" STARTARROW="None" STARTINCLINATION="167;5;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue