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 :)
http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html
