Lets talk about fibers

[Shachar Shemesh via Digitalmars-d]

On 05/06/15 16:44, Dmitry Olshansky wrote:
>
> * 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.
>

I see that people already raised the point that the OS does allow you to 
pin a thread to specific cores, so lets skip repeating that.

AFAIK, the kernel tries to keep threads running on the same core they 
did before is because moving them requires so much locking, synchronous 
assembly instructions and barriers, resulting in huge costs for 
migrating threads between cores.

Which turns out to be relevant to this discussion, because that will, 
likely, also be required in order to move fibers between threads.

A while back, a friend and myself ran an (incomplete) research project 
where we tried reverting to the long discarded "one thread per socket" 
model. It actually performed really well (much much better than the 
"common wisdom" would have it perform), provided you did two things:
1. Use a thread pool. Do not actually spawn a new thread each time a new 
incoming connection arrives
and
2. pin that thread to a core, don't let it migrate

Since we are talking about several tens of thousands of threads, each 
random fluctuation in the load resulted in the kernel's scheduler 
wishing to migrate them, resulting in losing thousands of percent worth 
of performance. Once we locked the threads into place, we were, more or 
less, on par with micro-threading in terms of overall performance the 
server could take.

Shachar