Remember that Go vs D MQTT thing and how we wondered about dmd vs gdc?

[Etienne]

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