Re: GNAT�and Tasklets

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

<vincent.diemunsch@gmail.com> wrote in message 
news:2d4fc21f-5739-4100-9551-959b6822c761@googlegroups.com...
>Hello Randy,
>
>Thank you for your response. I find it a little bit confusing in fact.
>
>> There is no such thing as a "lightweight Ada task". The syntax is heavy, 
>> the
>> semantics is heavy (separate stack, exception handling, finalization,
>> termination), and as a correlary, the implementation is heavy.
>
>Have you heard of Ravenscar ? The idea is to restrict tasking to a simple 
>subset
>that is both predictable, therefore easy to set up right, and light to 
>implement.
>I am pretty sure, that local tasks could be restricted a lot and yet be 
>very useful.
>And tasks with very limited synchronization, without rendez-vous, are easy 
>to
>manage.

Brad already answered this, so I'll just add that the stuff that makes these 
tasks expensive (a separate stack, finalization, exception handling, 
termination) can't be eliminated by Ravenscar-like restrictions. You could 
make draconian restrictions on what you can do in them, of course, but you'd 
be throwing out almost all of Ada's good parts if you did. (Ada without ADTs 
or exceptions is just another programming language, and an overly wordy one 
at that).

Also, Ravenscar gets much of its simplicity by having tasks that never 
terminate. That's because task termination in Ada is very complex, and 
pretty much the only way to simplify it is to ensure it doesn't happen. 
That's not going to work for your purposes (local tasks better stop or the 
containing subprogram can never return).

>> >Finaly, I really hope that the new version of the langage will keep Ada
>> >simple ...
>> That ship sailed with Ada 95, if it ever was true at all.
>
>So what ? We will continue to make it more and more complex ? Isn't it 
>possible
>to stop that trend and try to do better ?

No, it's not possible. Adding anything at all to the language makes it more 
complex, and compatibility concerns mean that almost nothing can be deleted. 
The only way to make a simpler language would be to start over, and that 
wouldn't be Ada anymore [doing that killed Algol 60, for instance].

The alternative way to keep the complexity the same is simply to give up and 
not change the language at all. But then it soon will end up in the museum 
of disused languages.

...
>> You are still thinking way too low-level. Creating a parallel program 
>> should
>> be as easy as creating a sequential one. There should (almost) be no 
>> special
>> constructs at all. Ideally, most programs would be made up of parallel 
>> loops
>> and blocks, and there would be hardly any tasks (mainly to be used for
>> separate conceptual things).

>That's funny ! Really are you serious ? Ada have created the task 
>abstraction
>to deal with parallelism, and for me it is an abstraction, that can be 
>implemented
>by different ways, depending on the compiler, the OS but also the way it is 
>used
>inside the program. First you are telling me that it is too difficult for a 
>compiler to
>implement this abstraction in an other way than a heavy OS thread, because 
>it
>would be to complex to automatically find simple cases allowing reduce 
>tasking,
>and because a runtime library using mixed tasking would be to difficult to 
>write.

There are no practical "simple" tasking cases. Every task has to terminate, 
deal with exceptions, deal with finalization, and the like. The only tasks 
that could eliminate those things would contain no calls, no uses of ADTs 
(meaning no containers), no heap use. And such tasks are too simple to be 
worth parallelizing anyway (see Dmitry's message and my reply to it).

Janus/Ada has some code-generation cases for cutting the costs of subprogram 
calls for very simple subprograms. And when I tested coverage of the code 
generator on our in-house collection of Ada test programs, it turned up as 
having never been tested. There was not a single usage of the "very simple" 
subprogram anywhere. It was just a bunch of work for no gain. That almost 
always happens with "simple" anythings.

>And strongly disagree to both arguments :
>1. the Ravenscar profile is a counter example, and using aspects or pragma 
>should
>allow us to make useful restrictions on local tasks
>2. the Paraffin library shows clearly that we can have mixed tasking, for 
>it can be
>used in parallel to tasks.
>And after, that you pretend seriously that a compiler should be able to 
>find by its
>own parallelism in the program ! It seems to me a major contradiction !

Surely, because you are inventing things. I'm not in favor of the compiler 
automatically doing anything, in large part because it violates the rules of 
Ada as they stand. I'm in favor of Brad's parallel loops and blocks, because 
they *declare* to the compiler that code should be executed in parallel if 
that makes sense. Plus there is static checking that the code is 
parallel-safe (or a suppression of such checking, so the compiler doesn't 
have to care whether it works).

The result is easy to read, easy to write, and relatively easy to compile. 
"Simple" in you description.

Writing tasks for short parallelization is just too heavyweight, especially 
as most people will not understand what is and is not allowed for 
communication. (And there are very few truly independent tasks.)

As an example, Ada 2005 used procedure parameters to do iteration. It works, 
it didn't add any new features or complexity -- and people hated it because 
it required inverting the way one thinks about a loop. So Ada 2012 added 
user-defined iterator syntax. The code does essentially the same thing, but 
it's much more readable (almost too readable since now people are 
complaining about the overhead).

We don't want to repeat that mistake; tasks are just too heavyweight to 
describe loop contents, just as subprograms are too heavyweight for the same 
purpose.

>No, creating a parallel program is far more complex than creating a 
>sequential
>one, and until we have a compiler so smart to do this, I prefer to rely on
>explicit tasking.

But that's the whole point: we HAVE to have a compiler smart enough to at 
least check this, else Ada will be passed by other languages that provide 
the same thing. Indeed, Ada's entire future is in having the compiler check 
a lot more things (both sequential and parallel). The proposed parallel loop 
construct will only allow code that is task-safe (we intend to allow a 
programmer to suppress the check, but it will default to safe).

There's no point in any half-measures; certainly not at the language level.

...
>> Also please note that language enhancements occur through a process of
>> consensus. Most of the ARG has to agree on a direction before it gets 
>> into
>> the language standard.
>
>That is why I am taking time to discuss on this forum.
>
>> You should have noted by now that pretty much everyone who has answered
>> here has disagreed with your position.
>
>No I haven't noticed.

Which is why I wrote this part of my reply. Please notice!

> I had the feeling that at least Dimitry and Brad had were
> sensible to some of my points.

Every squirrel finds some nuts. :-)

> But even if it was the case, that doesn't mean that
> I went wrong :-) Montesquieu said "The less you think, the more people 
> agree with you" :-).

And this IS the problem. You don't seem to understand that many of us have 
been working on this problem for many years, have already seen many failed 
solutions (your ideas are very similar to the passive tasks of Ada 83; Ada 
95 decided not to go that way for good reason), and have already been 
working on achieving consensus on a direction for the future. And you seem 
to be ignoring the reasons why we're going that way in favor of an unusual 
understanding of the purposes of tasks.

Anyway, this is pretty much my last attempt to discuss this. I realize that 
I've spent more than 2 hours writing messages here the last couple of days 
and I really ought to accomplish some work rather than throwing away more 
time.

                                      Randy.