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

[Etienne]

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