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