Lets talk about fibers

[Dmitry Olshansky via Digitalmars-d]

On 05-Jun-2015 17:04, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> 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?

You choose to ignore the point about duplicating the same memory in each 
core's cache. To me it seems like throwing random CPU technologies won't 
help make your argument stronger.

However I stand corrected - there are sys-calls to confine thread to 
specifics subset of cores. The point about cache stays as is as it 
assumed each thread prefers to run the same core vs e.g. always running 
on the same core.

> I need to think of this in terms of _smart_
> scheduling and adaptive load balancing.

Can't help you there, especially w/o definition of the first.

Adaptive load-balancing is quite possible with fibers sticking to a 
thread and is a question of application design.

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

I bet it still helps some workloads and hurts others without "me" 
scheduling anything. There are some things OS can do just fine.

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

Not sure if this is English, but I stand corrected in that one may set 
thread affinity for each thread manually. What I argued for is that 
default is mostly the same and the point stands as is.

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

I haven't said performance. Fast and incorrect is cheap.

> only TLS (which is a
> questionable feature to begin with).

Aye, no implicit data-races by default is questionable design. What 
questions do you have?


-- 
Dmitry Olshansky