On 12 March 2014 18:05, Etienne <etci...@gmail.com> wrote: > On Wednesday, 12 March 2014 at 15:11:45 UTC, Etienne wrote: >> >> On Wednesday, 12 March 2014 at 12:10:04 UTC, Bienlein wrote: >>> >>> On Wednesday, 12 March 2014 at 09:26:28 UTC, Sönke Ludwig wrote: >>> >>>> I actually don't see a reason why it can't be just as efficient when >>>> done as a library. Taking the example of vibe.d, fibers are currently never >>>> moved between threads (although technically, they could), but they are >>>> still >>>> stored in a free list and reused for later tasks. >>> >>> >>> I believe several kernel threads are in the play to call fibers. Then the >>> free list must be synchronized which can make a difference on a heavy loaded >>> system at the end of the day. HawtDispatch >>> (http://hawtdispatch.fusesource.org) applies some tricks to reduce >>> synchronization on its free lists for that reason. But I honestly don't have >>> a clue how that exactly works. >> >> >> Bypassing the kernel could be more efficient for fibers if it were >> possible, and using thread affinity it could remove some interruption by >> setting the maxcpus option in the kernel. The alternative to locking via >> kernel is queuing using the freeway overpass method described here: >> http://blog.erratasec.com/2013/02/multi-core-scaling-its-not-multi.html I >> think HawtDispatch may be using queues to fit into this synchronization >> method. Snort is also a good example of mostly lock-less multi-core by using >> "memory mapped regions" >> >> I'm also very interested in optimizing fibers further as it would give D >> excellence where it already does great > > > I think this article puts it well. Bypassing the kernel for fibers should be > a long-term plan :) >
Not just fibers, but the entire synchronisation stack - which is currently just a wrap around pthreads/winthreads.