Re: Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?")

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 03 Mar 2007 18:28:18 +0100, Pascal Obry wrote:

> Dr. Adrian Wrigley a �crit :
>> Numerous algorithms in simulation are "embarrassingly parallel",
>> but this fact is completely and deliberately obscured from compilers.
> 
> Not a big problem. If the algorithms are "embarrassingly parallel" then
> the jobs are fully independent. In this case that is quite simple,
> create as many tasks as you have of processors. No big deal. Each task
> will compute a specific job. Ada has no problem with "embarrassingly
> parallel" jobs.
>
> What I have not yet understood is that people are trying to solve, in
> all cases, the parallelism at the lowest lever. Trying to parallelize an
> algorithm in an "embarrassingly parallel" context is loosing precious
> time. Many real case simulations have billions of those algorithm to
> compute on multiple data, just create a set of task to compute in
> parallel multiple of those algorithm. Easier and as effective.
>
> In other words, what I'm saying is that in some cases ("embarrassingly
> parallel" computation is one of them) it is easier to do n computations
> in n tasks than n x (1 parallel computation in n tasks), and the overall
> performance is better.

The idea (of PAR etc) is IMO quite opposite. It is about treating
parallelism rather as a compiler optimization problem, than as a part of
the domain. In the simplest possible form it can be illustrated on the
example of Ada's "or" and "or else." While the former is potentially
parallel, it has zero overhead compared to sequential "or else." (I don't
count the time required to evaluate the operands). If we compare it with
the overhead of creating tasks, we will see a huge difference both in terms
of CPU cycles and mental efforts.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de