[Bf-committers] Curious about 'SetThreadGroupAffinity()'
Brecht Van Lommel
brechtvanlommel at gmail.com
Mon May 28 13:40:42 CEST 2018
We use SetThreadGroupAffinity() for systems with more than 64 cores,
without that it doesn't use all the cores.
SetThreadAffinityMask() is a hint to the operating system scheduler, which
can improve performance by some % due to fewer context switches or better
memory location for example. If you have just a single process with a
single thread pool with the same amount of threads and cores a hint can
But if you have multiple processes, multiple thread pools, external
renderers doing their own threading, ... then the optimal scheduling is not
so obvious and giving the wrong hints can cause higher priority tasks to be
slowed. Adding affinity may still help, but it would need detailed
benchmarking, and even then it's a bit risky because it might be worse in
some corner cases we didn't predict. Generally the operating system
scheduler does a good job, and these schedulers have gotten better in newer
operating systems too.
On Mon, May 28, 2018 at 12:15 PM, John Emmas <john at creativepost.co.uk>
> Hi guys - forgive me asking a trivial question. It's just something I
> noticed in the Blender code...
> I'm involved mostly in audio products where we often use multiple threads
> to run things like the processing stuff (plugins etc). On Windows we'll
> call functions like 'SetThreadAffinityMask()' or
> 'SetThreadIdealProcessor()' to ensure that multiple threads get run on
> different CPU cores which gives an element of parallel processing (assuming
> there's enough cores available).
> But looking through the Blender code it seems like you've chosen a
> different approach ('SetThreadGroupAffinity()'). I might be
> misunderstanding something but AFAICT that'll assign threads to a processor
> group (rather than any individual processor). So it won't necessarily
> promote parallel processing. Or isn't that the reason? Do you use that
> approach because it offers some other benefit? Like I said, I'm just
> curious really...
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers