On 02/11/2010 03:26, Robert Jacques wrote:
On Mon, 01 Nov 2010 10:24:43 -0400, Bruno Medeiros
<brunodomedeiros+s...@com.gmail> wrote:
On 29/10/2010 02:32, Robert Jacques wrote:
[snip]
The programming language Cilk popularized the concept of parallelization
through many small tasks combined with a work stealing runtime. Futures
are essentially the same concept, but because futures were generally
implemented with OS-threads, a thread pool or fibers/coroutines, that
term is generally avoided. Like message passing, tasks are often
implemented in libraries with Intel's threading building blocks probably
being the most famous, though both Microsoft's Task Parallel Library and
Apple's Grand Central are gaining mind-share. David Simcha currently has
a task library in review for inclusion to phobos. Basically, the point
of tasks is to provide parallelization with extremely low overhead (on
average a Cilk spawn is less than 4 function calls). That way, instead
of having a few coarse grain threads which neither scale nor load
balance well, you're encouraged to use tasks everywhere and therefore
reap the benefits of a balanced N-way scalable system.
Hum, I see what you mean know, but tasks only help with the *creation
overhead* of otherwise spawning lots of OS threads, they don't solve
the main problems I mentioned.
First, it may be fine to spawn 100 tasks, but there is still the issue
of deciding how many OS threads the tasks will run in! Obviously, you
won't run them in just one OS thread, otherwise you won't get any
parallelism. Ideally for your program only, your program would have as
many OS threads as there are cores. But here there is still the same
issue of whether its ok for you program to use up all the cores in
your machine. The compiler doesn't know that. Could it be enough to
have a global compiler option to specify that? I don't think so: What
if you want some code of your program to use as much OS-threads as
possible, but not some other code?
Second, and perhaps more importantly, the very same issue occurs in
the scope of your program alone. So, even if you use all OS threads,
and don't care about other programs, spawning 100 tasks for some loop
might take time away from other more important tasks of your program.
The compiler/task-scheduler/whatever would not automatically know what
is acceptable and what is not. (the only exception being if your
program was logically single-threaded)
Controlling the task runtime thread-pool size is trivial. Indeed, you'll
often want to reduce the number of daemon threads by the number of
active program threads. And if you need fine grain control over pool
sizes, you can always create separate pools and assign tasks to them. I
think a reasonable default would be (# of cores - 2) daemons with
automatic decreases/increases with every spawn/termination. But, all
those settings should be controllable at runtime.
I didn't say controlling pools/task-count/threads-count/priorities
wasn't easy or trivial. I just claimed it should not done automatically
by the compiler, but rather "manually" in the code, and with fine
grained control.
∎
--
Bruno Medeiros - Software Engineer
