las3_pub / predictable_parallel_patterns

Everything so far is untested. We only made sure tha fast path still seems to function correctly. Next up is writing tests for both the fast and slow path to then introduce the slow path. After that we can look at performance optimizations.

This showcases the expected performance when a task executes a sub-tree without inference from other threads. We target to stay about 6x slower than a normal function call.

This first sketch of the classes captures what we think is needed in terms of general interface and very mich WIP.

We changed how the memory is allocated from passing char* buffers to then store objects into to creating 'fat objects' for all scheduler state. This eases development for us, as we can make changes to data structures without too much effort (e.g. add a second array to manage tasks if required).

Our stack is not calling deconstructors of its elements. This is problematic for e.g. the graph implementation where reference counted images are hold in tasks. To solve this for now we manually call the deconstructor after each tasks (we do so, because a generic, virtual deconstructor adds runtime costs to primitive tasks, requiring us to re-run all benchmarks; with this change we do not need to do this and as we re-work the scheduler anyways we postpone a clean implementation for then).

This allows us to more easily handle them and makes their interface closer to std::thread.

The scheduler yields if it failed to steal any work due to the task
lists being empty. This should improve performance on multiprogrammed
systems, as it potentially makes room for other worker threads which
still have work to perform.

This might allow us to do lock free, conditional waits in our stealing loop.

This allows the stack and deque class to use the same offset, making it work better with each other.

Merge: Dataflow

See merge request !12

Now end users only have to #include<pls/dataflow/dataflow.h> to use all parts of the API. We split dataflow out from the general algorithms header, as it is a rather big API and could bloat the users namespace/includes.

This makes the programming model a full dataflow implementation, as it allows for branching and recursion.

Recursion works by using a function node, calling the graph again. We separated an graph invocation form an function invocation within an graph, making the graph only handle one concern.

Now all expressions in the assert macro are enclosed in parentheses, avoiding issues.

We separated the structure (input-output flow) from the rest of the architecture and reworked some template programming to have better access to the types required at compile time.

The data can now flow into a graph, follow its path on inptus/outputs and be fetched from the graph after execution.
Currently graphs are executed synchronous.

The data can now flow into a graph, follow its path on inptus/outputs and be fetched from the graph after execution.
Currently graphs are executed synchronous.

We need some tricks in template programming to have a clean user facing API while internally using our classes with more capabilities.

We need some tricks in template programming to have a clean user facing API while internally using our classes with more capabilities.

This is the base building block for creating the actual dataflow functions and networks, as their main functionality is having data flow through connected nodes.