Proposal: Relax rules for 'pure'

[Bruno Medeiros]

On 02/11/2010 03:26, Robert Jacques wrote:
> On Mon, 01 Nov 2010 10:24:43 -0400, Bruno Medeiros
> <brunodomedeiros+spam at 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