Re: GNAT and Tasklets

["Randy Brukardt" <randy@rrsoftware.com>]

<vincent.diemunsch@gmail.com> wrote in message 
news:f9828477-a98e-4795-803d-5926aa7a1fdb@googlegroups.com...
...
>I am rather surprised that you made a distinction between creating tasks
>and parallelism. I agree that the goal of parallelism is to increase CPU
>usage and therefore make the program run faster. For me creating tasks is
>the Ada way of implementing parallelism. And it is a sound way of doing it
>since compilers, as far as I know, are not really able to find automaticaly
>parallelism in a program. Moreover using things like state machines to
>create parallelism is to complex for a programmer and needs the use of a
>dedicated langage. So tasks are fine.

No, tasks are *not* fine. They are far too heavy-weight for the average 
programmer (or even the one that wants to accomplish something fast). And it 
is far too easy to introduce race conditions or deadlocks into them. On top 
of which (as Brad notes), the optimal parallelism structure depends on the 
actual OS/hardware that you run on. You surely don't want to have to encode 
that into your program and redo it everytime you find out about a better way 
to work on a particular target.

For a lot of uses, what you want is a parallel block or loop that eliminates 
the implicit sequential behavior. In that case, the compiler can execute the 
code in parallel or sequentially depending on the actual execution 
environment. But to make that easy *and* safe, there have to be restrictions 
on what you can put into such constructs. That's what the group of four are 
looking at (and I would, if I could spare the time).

Tasks are good for separating relatively large and loosely related jobs. 
They work great for dealing with web server requests, for instance, because 
the requests don't need to talk to each other and just need to do whatever 
they do. They're not a very good way to split up a single calculation, 
because the granularity is almost certainly going to be too coarse (not 
enough parallelism) or too fine (too much overhead), and they're too 
inflexible to be able to change that on the fly.

                                       Randy.