las3_pub / predictable_parallel_patterns

The flag can be used to run code annotated with PLS outside of a scheduler environment,
i.e. the app does not crash if the code is called without context. The compile option
allows to omit all spawn and sync calls during compilation, creating the equivalent serial code.

Remove easy profiler for now. It might be useful for later on to get a grasp of general behaviour, but because of its issues with coroutines it is not worth profiling code with it right now.

It is now possible to use a memory mapped stack that throws a SIGSEV if thes coroutine stacks are exhausted.

Older CMAKE versions wont work with export targets in different directories. For now we simply add the context_switcher manually to the export target of pls.

We still see very sporadic crashes, however the current version is at least a starting point for refactoring and debugging. Next steps have to be to re-enable tooling support (i.e. add code to let sanitizers do their work).

The idea is to exclude as many sources as possible that could lead to issues with contention and cache misses. After some experimentation, we think that hyperthreading is simply not working very well with our kind of workload. In the future we might simply test on other hardware.

This version runs through our initial fft and fib tests. However, it is not tested further in any way. Additionally, we added a locking deque, potentially hurting performance and moving away from our initial goal.

The main issue seems to still be the fact that we have a lock free protocol where a steal can be pending. We plan to remove this fact next by introducing a protocol that works on a single atomic update.

We changed up some of the memory constraints in the lock free deque and will need to see if this is ok. If so, the single threaded performance looks very good.

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

Now all algorithms are used without the parallel pre-/suffix and the for_each method has an specialization for integer ranges.

We do this to properly separate the cache alginment logic in the next step, allowing us to port all cache aligned objects without worrying about portability.