Lets talk about fibers

via Digitalmars-d digitalmars-d at puremagic.com
Fri Jun 5 07:04:04 PDT 2015


On Friday, 5 June 2015 at 13:44:16 UTC, Dmitry Olshansky wrote:
> 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.

If you cannot control affinity then you can't take advantage of 
hyper-threading either? I need to think of this in terms of 
_smart_ scheduling and adaptive load balancing.

> Moving fibers across threads have no effect on all of the above 
> even if there is some truth.

In order to get benefits from hyper-threading you need pay close 
attention how you schedule, or you should turn it off.

> There is simply no way to control what core executes which 
> thread to begin with, this assignment is the OS territory.

If your OS is does not support hyper-threading level control you 
should turn it off...

>> 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.

No, there were no performance related reasons, only TLS (which is 
a questionable feature to begin with).

> 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.

There is nothing to prove. You either perform worse or better 
than a carefully scheduled event-based solution in C++. You 
either perform worse or better than Go 1.5 in scheduling and GC.

However, doing well in externally designed and executed 
benchmarks on _language_ _features_ is good marketing (even if 
that 10-20% edge does not matter in real world applications).

Right now, neither concurrency or GC are really D language 
features, they are more like library/runtime features. That makes 
it difficult to excel in those areas. In languages like Go, 
Erlang and Pony concurrency is a language feature.



More information about the Digitalmars-d mailing list