Re: GThreads and GThreadPool help for a dummy

[richard boaz <ivor.boaz@xxxxxxxxx>]

indeed.  the way i solve this is by programmatically determining the number of CPU's available on the machine at program startup, knowing (through testing) how much of the CPU a particular task requires, taken in conjunction with how much the program should be allowed to "take over" the machine.  and then starting the maximum number of threads determined by all of these (there's probably even more one could consider here).  all programmable, thus always making best use of all available CPU's vs. requirements vs. known trade-offs.

further, by knowing how many data elements are required to be processed, if this number is actually less than the computed allowed maximum number of threads, then this becomes the maximum number of threads to be started.  (no sense starting more worker threads than there are elements to be processed.)

another thing i left out is adding a progress meter.  when the app is a GUI, indications back to the user how far along the task is, (if the task requires say more than 2 seconds), is good practice, and will make your users happy.  this is easily  achieved by adding a call to g_idle_add() in the worker thread to invoke a routine responsible for updating a progress meter.  since the main loop is not blocked, screen refresh is immediate (assuming you've left space on the CPU's to allow the computer to do more work than just the worker threads).

richard

On Sat, Jul 24, 2010 at 4:03 AM, Robert Pearce <rob@xxxxxxxxxxxxxxxxxxxx> wrote:

On Sat, 24 Jul 2010 10:16:09 +0200 richard wrote:
>
> And, while I'm here, a couple of relevant guidelines to writing
> multi-threaded code:

There's another that you've missed:

 - Use as few threads as possible.

Basically, threads add overhead. You get benefit only up to the point where there are as many threads as you have independent CPU cores. Beyond that your performance drops off as compared to a well structured idle loop, and the readability isn't noticeably better either.

If you want to sum the results of foo(x[i]) over an array of N elements, where N is large and foo() is simple, I wouldn't use threads. If this is a background task and you want GTK to remain responsive, I would launch exactly ONE thread to do the summing. If foo() is complex, I would split N into M ranges, where M is roughly the number of CPU cores you expect to have, and launch M threads. Only if N is approximately equal to M would I take the approach being discussed here.

Rob

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list