Lets talk about fibers

[Dicebot via Digitalmars-d]

On 04/16/2016 03:45 PM, maik klein wrote:
> Here is an interesting talk from Naughty Dog
> 
> http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine
> 
> They move Fibers between threads.
> 
> A rough overview:
> 
> You create task A that depends on task B. The task is submitted as a
> fiber and executed by a thread. Now task A has to wait for task B to
> finish so you hold the fiber and put it into a queue, you also create an
> atomic counter that tracks all dependencies, once the counter reaches 0
> you know that all dependencies have finished.
> 
> Now you put task A into a queue and execute a different task. Once a
> thread completes a task it looks into the queue and checks if there is
> one task that has a counter of 0, which means it can continue to execute
> that task.
> 
> Now move that fiber/task onto a free thread and you can continue to
> execute that fiber.
> 
> What is the current state of fibers in D? I have asked this question on
> SO
> https://stackoverflow.com/questions/36663720/how-to-pass-a-fiber-to-a-thread

Such design is neither needed for good concurrency, nor actually
helpful. Under heavy load (and that is the only case that is worth
optimizing for) there will be so many fibers that thread-local fiber
queues will always have enough work to keep them busy.

At the same time moving fibers between threads is harmful for plain
performance - it screws the cache and makes impossible to share
thread-local storage between fibers on same worker thread.

Simply picking a worker thread + worker fiber when task is assigned and
sticking to it until finished should work good enough. It is also
important to note though that "fiber" is not the same as "task". Former
is execution context primitive, latter is scheduling abstraction. In
fact, heavy load systems are likely to have many more tasks than fibers
at certain spike points.