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

[Iain Buclaw]

On 12 March 2014 18:05, Etienne <etcimon at 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.