Lets talk about fibers

[Dmitry Olshansky via Digitalmars-d]

On 05-Jun-2015 14:29, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Thursday, 4 June 2015 at 22:28:52 UTC, Jonathan M Davis wrote:
>> anyone give a reason why we need to. deadalnix talked about load
>> balancing that way, but you gave good reasons as to why that didn't
>> make sense,
>
> What good reasons?
>
> By the time you get response from your shared memcache or database the
> x86 cache level 1 and possibly 2 is cold.

Cache arguments are hard to get right w/o experiment. That "possibly" 
may be enough compared to certainly cold.

However I'll answer theoretically to equally theoretical argument.

If there is affinity and we assume that OS schedules threads on the same 
cores*  then each core has it's cache loaded with (some of) stacks of 
its fibers. If we assume sharing fibers across all cores, then each core 
will have to cache stacks for all of fibers which is wasteful.

So fiber affinity => that much less burden on each of core's caches, 
making them that much hotter.

* You seem to assume the same. Fine assumption given that OS usually 
tries to keep the same cores working on the same threads, for the 
similar reasons I believe.

>  Add to this that
> two-and-two cores share primary caches so if you don't pair tasks that
> address the same memory you loose up to 10-20% performance in addition
> to unused capacity and increased latency. Smart scheduling matters, both
> at the OS level and at the application level. That's not a controversial
> statement (only in these forums…)!

Moving fibers across threads have no effect on all of the above even if 
there is some truth. There is simply no way to control what core 
executes which thread to begin with, this assignment is the OS territory.

>
> The only good reason for not switching is that you lack
> resources/know-how.

Reasons were presented, but there is nothing in your answer that at 
least acknowledges that.

> But then you probably should not make it a language
> feature in the first place...?

Then it's a good chance for you to prove your design by experimentation. 
That if we all accept concurrency issues with moving fibers that violate 
some language guarantees.

-- 
Dmitry Olshansky