Unfortunately, that's not a scheduler. So yes, the windows scheduler is still the only thing that can bounce threads around onto the 'best' core. I did make a confusing statement alright in my last post, what i was trying to say is that there's no way to automatically bounce threads between cores so that all threads are spread evenly. Of course, there's a way to automatically set affinity. C# exposes this, the task manager exposes this (if you care to check it out) and any program can expose this facility.
However, you're still left with the extremely difficult task of finding the best core for each and every thread.
Load balancing != choosing a specific core.
Parallel programming != choosing specific cores.
Performance counters can give you this information on cpu usage etc, but if you want to even attempt to utilise this you are essentially implementing a userland scheduler, which runs under the windows scheduler, and as I said before - will be constrained by the windows scheduler.
Load balancing is good - setting tasks to a specific core is bad unless you know that no other application will be choosing that specific core.
Not an embedded system. Not one which has 1000 cores in a single box. One which does not use a third party scheduler which overrides cpu affinity set by a program.
I have seen benchmarks where the the library was used incorrectly/badly.
http://garuma.wordpress.com/2008/07/...ith-a-p-twist/
The parallel library can improve performance significantly when it's used for a suitable task. Once again, this has nothing to do with setting specific tasks to specific cores.
1) So, setting a specific task to a specific core is still bad.
2) Yes you can get performance counter information from windows - no i really don't believe you can implement a userland scheduler which will outperform the built in scheduler. However, i haven't ever seen a userland scheduler nor am I going to implement such a thing to prove my point.
3) Splitting up a large task and letting the OS schedule that work onto the best core is good. It's what people have been doing for years and will continue do to for decades to come.
4) It is still hard to tell from usercode which core is good because you never know what tasks will be starting/stopping at any given instant. A userland scheduler will just be a poor and slow imitation of the windows scheduler.
And that's me for this thread. I can't make my point any clearer and I have yet to see a good rebuttal for my basic point:
If you force an intensive task to core0 and there's already an intensive task on core0 - you've just cut your performance.