Re: basic question on Ada tasks and running on different cores

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

"NatarovVI" <4KCheshireCat@gmail.com> wrote in message 
news:jp0ikh$b7q$1@speranza.aioe.org...
>> Sure, but I'm skeptical that the vast majority of programmers can deal
>> with any programming language that has the level of non-determinism
>> needed to support useful parallelism. Functional programming languages
>> make this worse, if anything.
>
> and again - "parallelism is not concurrency"
> if first-course CMU students can write correct parallel programs,
> everybody can.

Baloney. First-course students don't have to worry about any real-world 
constraints. It's easy to write any kind of program in that environment (it 
was much easier to write programs of all sorts when I was a student).

> right abstractions is the key.
> read Robert Harper experience at existentialtypes.wordpress.com

I'm dubious of the pronouncements of anyone who's income (in this case, 
research grants) depends on people believing those pronouncements. In any 
case, those who ignore history are doomed to repeat it, and there has been 
research into these areas for 50 years. No one yet has found the "holy 
grail" of "free parallelism", and moreover nothing here is new.

Besides, 90% of most applications is I/O. The computation part of most 
programs is quite small. If all you can do is speed those things up, it's 
not going to make a significant difference to most programs. There are, of 
course, a few parts of programs that do extensive computations, but often 
these are in libraries where it makes sense to spend special efforts.

>> Secondly, I'm skeptical that any language attempting fine-grained
>> parallelism can ever perform anywhere near as well as a language using
>> coarse parallelism (like Ada) and deterministic sequential semantics for
>> the rest. Any parallelism requires scheduling overhead, and that
>> overhead is going to be a lot higher for the fine-grained case, simply
>> because there is a lot more of it needed (even if it is conceptually
>> simpler).
>
> you really need 100% of performance?

Of course, for the most critical computations. If you don't need 100% of 
performance, then you surely don't need parallel execution - what could 
possibly be the point?? Using two cores instead of one to do a computation 
that is not critical is insane -- you end up using more power to do the same 
work in the same time -- meaning more heat, lower battery life, etc.

> maybe you like write in asm?))

If necessary. But high-quality compilers can (or should) generate better 
code than you can write by hand, because they can take into account many 
more variables than a hand-programmer can. So the vast majority of the time, 
writing critical code in Ada is enough. (But, yes, Janus/Ada does have a few 
hand-coded ASM lookup loops; those cut compilation time by 25% when they 
were implemented. [No idea if they're needed anymore, of course, the CPU and 
I/O balance has changed a lot in the last 30 years.])

The problem is, if you're trying to implement fine-grained parallelism, you 
have to surround that code with some sort of scheduling mechanism, and that 
overhead means you aren't going to get anywhere near 100% of the CPU at any 
point. That means you'll have to find a

> seriously, SISAL and NESL can automatically get good part of data
> parallelism, no magic here. and this will be enought for most programmers.

Most programmers need no parallelism at all; they just need a good graphics 
library that uses parallelism to do their drawning. (And possibly a few 
other libraries.) The point is, most programmers are writing I/O intensive 
applications that do little computation (think of the apps on your phone, 
for example).

> (high order functions will be requirement here, extending data
> parallelism to operations on functions)

Certain special cases surely exist, and those can be implemented in a 
compiler for almost any language. (At the very least, by well-defined 
libraries.) These things surely could be done in Ada, either via libraries 
(look at Brad Moore's work) or via language-defined primitives. As I've said 
all along, I've very skeptical that anything further will prove practical.

> p.s. best scheduling is no scheduling...

Right. But that's only possible using vector instructions and the like; 
that's a *very* small set of all computing. (I doubt that I have ever 
written a program -- in 30+ years -- that could have been helped by a vector 
instruction.) Any other sort of parallelism will have to be implemented by 
some sort of concurency, and that requires some sort of scheduling.

>> going on today :-), I don't see it happening. I wouldn't mind being
>
> it will happen)) and Ada - not only language without need for debugging.
> Standard ML also.

I can believe that; no one has a clue what an ML program means, so there is 
no need to debug it - discarding makes more sense. ;-) Ada is the only true 
syntax. :-)

                                      Randy.