[Foxgui-users] How to limit the number of CPUs used by a FXThreadPool ?

[pof]

Dear all,

I have been using for a long time now (several years) a parallelization
of some computation method using a FXThreadPool, which can typically
contain in my case between 1e3 to 1e6 Worker-Threads.
This works nicely as it distribute computing load to all available CPUs.

In some situations, it could be interesting to limit the number of CPUs
used by the FXThreadPool, for instance to keep some CPU available for
other tasks or other applications.
I have looked around, but I did not find an obvious way to do that.
Any idea or hint are welcome.

Cheers
Pof

[JVZ]

On Tue, 5 Jul 2016 23:15:30 +0200

Post by pof
Dear all,
I have been using for a long time now (several years) a parallelization
of some computation method using a FXThreadPool, which can typically
contain in my case between 1e3 to 1e6 Worker-Threads.
This works nicely as it distribute computing load to all available CPUs.
In some situations, it could be interesting to limit the number of CPUs
used by the FXThreadPool, for instance to keep some CPU available for
other tasks or other applications.
I have looked around, but I did not find an obvious way to do that.
Any idea or hint are welcome.
Cheers

FXThreadPool's setMaximumThreads() API should accomplish this; please note,
this is the maximum. You can also set the minimum.

The number of worker threads can fluctuate due to the amount of work submitted
to the FXThreadPool. In very bursty job-load cases, you may want to let all
threads that fall idle eventually terminate, and thus release lots of system-
resources back, when no tasks are available to keep them busy.

However, if lost of jobs suddenly arrive then new threads need to be started
before parallelism is achieved. This takes some time.

Depending on your processing latency requirement, you can keep all threads
around by setting the minumum equal to the maximum.

You do not need to devote all processors in the system to the FXThreadQueue;
this may not be optimal as some libraries may want to kick off thread on their
own [for example, Intel MKL or OpenBLAS seem to be guilty of this].


Hope this helps,

-- JVZ

[pof]

Post by JVZ
On Tue, 5 Jul 2016 23:15:30 +0200

Post by pof
Dear all,
I have been using for a long time now (several years) a parallelization
of some computation method using a FXThreadPool, which can typically
contain in my case between 1e3 to 1e6 Worker-Threads.
This works nicely as it distribute computing load to all available CPUs.
In some situations, it could be interesting to limit the number of CPUs
used by the FXThreadPool, for instance to keep some CPU available for
other tasks or other applications.
I have looked around, but I did not find an obvious way to do that.
Any idea or hint are welcome.
Cheers

FXThreadPool's setMaximumThreads() API should accomplish this; please note,
this is the maximum. You can also set the minimum.
The number of worker threads can fluctuate due to the amount of work submitted
to the FXThreadPool. In very bursty job-load cases, you may want to let all
threads that fall idle eventually terminate, and thus release lots of system-
resources back, when no tasks are available to keep them busy.
However, if lost of jobs suddenly arrive then new threads need to be started
before parallelism is achieved. This takes some time.
Depending on your processing latency requirement, you can keep all threads
around by setting the minumum equal to the maximum.
You do not need to devote all processors in the system to the FXThreadQueue;
this may not be optimal as some libraries may want to kick off thread on their
own [for example, Intel MKL or OpenBLAS seem to be guilty of this].
Hope this helps,
-- JVZ

Dear Jeroen,

Thanks for this info, but I am actually using setMaximumThreads() API (I
should have said that in my initial mail), and this does not produce any
change: the workload remains distrbuted amongst all processors (even
using setMaximumThreads(1) and setMinimumThreads(1)).

Btw, I am using 64 bits Windows 10, with visual C++2010.

Pof

[JVZ]

On Wed, 6 Jul 2016 07:19:49 +0200

Post by pof

Post by JVZ
On Tue, 5 Jul 2016 23:15:30 +0200

Post by pof
Dear all,
I have been using for a long time now (several years) a parallelization
of some computation method using a FXThreadPool, which can typically
contain in my case between 1e3 to 1e6 Worker-Threads.
This works nicely as it distribute computing load to all available CPUs.
In some situations, it could be interesting to limit the number of CPUs
used by the FXThreadPool, for instance to keep some CPU available for
other tasks or other applications.
I have looked around, but I did not find an obvious way to do that.
Any idea or hint are welcome.
Cheers

FXThreadPool's setMaximumThreads() API should accomplish this; please note,
this is the maximum. You can also set the minimum.
The number of worker threads can fluctuate due to the amount of work submitted
to the FXThreadPool. In very bursty job-load cases, you may want to let all
threads that fall idle eventually terminate, and thus release lots of system-
resources back, when no tasks are available to keep them busy.
However, if lost of jobs suddenly arrive then new threads need to be started
before parallelism is achieved. This takes some time.
Depending on your processing latency requirement, you can keep all threads
around by setting the minumum equal to the maximum.
You do not need to devote all processors in the system to the FXThreadQueue;
this may not be optimal as some libraries may want to kick off thread on their
own [for example, Intel MKL or OpenBLAS seem to be guilty of this].
Hope this helps,
-- JVZ

Dear Jeroen,
Thanks for this info, but I am actually using setMaximumThreads() API (I
should have said that in my initial mail), and this does not produce any
change: the workload remains distrbuted amongst all processors (even
using setMaximumThreads(1) and setMinimumThreads(1)).
Btw, I am using 64 bits Windows 10, with visual C++2010.

Hmm, did you call setExpiration() to make the threads fall out of the work-loop?

Threads can only drop out when they're not blocking for the queue. And if the
expiration time is infinite, they will block forever unless there are tasks.

The idea is that threads in excess of the minimum number hang in there for a little
bit, waiting for tasks, before self-termination.

So its necessary to set the expiration time (the maximum time waiting on the queue
for jobs to show up) should typically be set when the maximum number of threads
is larger than the minimum....


Hope I explained this well,...



-- JVZ

[Sander Jansen]

I think what he wanted was being able to set the affinity mask on the
threads of the threadpool. So you can actually restrict which cpus are
being used by the threadpool.

Sander

Post by JVZ
On Wed, 6 Jul 2016 07:19:49 +0200

Post by pof

Post by JVZ
On Tue, 5 Jul 2016 23:15:30 +0200

Post by pof
Dear all,
I have been using for a long time now (several years) a parallelization
of some computation method using a FXThreadPool, which can typically
contain in my case between 1e3 to 1e6 Worker-Threads.
This works nicely as it distribute computing load to all available

CPUs.

Post by pof

Post by JVZ

Post by pof
In some situations, it could be interesting to limit the number of CPUs
used by the FXThreadPool, for instance to keep some CPU available for
other tasks or other applications.
I have looked around, but I did not find an obvious way to do that.
Any idea or hint are welcome.
Cheers

FXThreadPool's setMaximumThreads() API should accomplish this; please

note,

Post by pof

Post by JVZ
this is the maximum. You can also set the minimum.
The number of worker threads can fluctuate due to the amount of work

submitted

Post by pof

Post by JVZ
to the FXThreadPool. In very bursty job-load cases, you may want to

let all

Post by pof

Post by JVZ
threads that fall idle eventually terminate, and thus release lots of

system-

Post by pof

Post by JVZ
resources back, when no tasks are available to keep them busy.
However, if lost of jobs suddenly arrive then new threads need to be

started

Post by pof

Post by JVZ
before parallelism is achieved. This takes some time.
Depending on your processing latency requirement, you can keep all

threads

Post by pof

Post by JVZ
around by setting the minumum equal to the maximum.
You do not need to devote all processors in the system to the

FXThreadQueue;

Post by pof

Post by JVZ
this may not be optimal as some libraries may want to kick off thread

on their

Post by pof

Post by JVZ
own [for example, Intel MKL or OpenBLAS seem to be guilty of this].
Hope this helps,
-- JVZ

Dear Jeroen,
Thanks for this info, but I am actually using setMaximumThreads() API (I
should have said that in my initial mail), and this does not produce any
change: the workload remains distrbuted amongst all processors (even
using setMaximumThreads(1) and setMinimumThreads(1)).
Btw, I am using 64 bits Windows 10, with visual C++2010.

Hmm, did you call setExpiration() to make the threads fall out of the work-loop?
Threads can only drop out when they're not blocking for the queue. And if the
expiration time is infinite, they will block forever unless there are tasks.
The idea is that threads in excess of the minimum number hang in there for a little
bit, waiting for tasks, before self-termination.
So its necessary to set the expiration time (the maximum time waiting on the queue
for jobs to show up) should typically be set when the maximum number of threads
is larger than the minimum....
Hope I explained this well,...
-- JVZ
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Foxgui-users mailing list
https://lists.sourceforge.net/lists/listinfo/foxgui-users