Curious about 'SetThreadGroupAffinity()'

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Curious about 'SetThreadGroupAffinity()'

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

John
_______________________________________________
Bf-committers mailing list
[hidden email]
https://lists.blender.org/mailman/listinfo/bf-committers
Reply | Threaded
Open this post in threaded view
|

Re: Curious about 'SetThreadGroupAffinity()'

Brecht Van Lommel-4
Hi,

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

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.

Regards,
Brecht.



On Mon, May 28, 2018 at 12:15 PM, John Emmas <[hidden email]>
wrote:

> 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...
>
> John
> _______________________________________________
> Bf-committers mailing list
> [hidden email]
> https://lists.blender.org/mailman/listinfo/bf-committers
>
_______________________________________________
Bf-committers mailing list
[hidden email]
https://lists.blender.org/mailman/listinfo/bf-committers
Reply | Threaded
Open this post in threaded view
|

Re: Curious about 'SetThreadGroupAffinity()'

John Emmas
Great explanation, Brecht - thanks !

John

On 28/05/2018 12:40, Brecht Van Lommel wrote:

> Hi,
>
> 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
> help.
>
> 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.
>
> Regards,
> Brecht.
>
>
>
> On Mon, May 28, 2018 at 12:15 PM, John Emmas <[hidden email]>
> wrote:
>
>> 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...
>>
>> John
>> _______________________________________________
>> Bf-committers mailing list
>> [hidden email]
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> [hidden email]
> https://lists.blender.org/mailman/listinfo/bf-committers
>

_______________________________________________
Bf-committers mailing list
[hidden email]
https://lists.blender.org/mailman/listinfo/bf-committers