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

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

On Sat, 03 Mar 2007 12:12:10 +0000, Simon Farnsworth wrote:

> Jonathan Bromley wrote:
> 
>> On Sat, 3 Mar 2007 12:00:08 +0100, "Dmitry A. Kazakov"
>> <mailbox@dmitry-kazakov.de> wrote:
>> 
>>>> The compiler should be able to generate code which generates a
>>>> reasonable number of threads, depending on the hardware being used.
>>>
>>>Yes
>> 
>> For heaven's sake...   You have a statically-determinable number of
>> processors.  It's your (or your compiler's) choice whether each of
>> those processors runs a single thread, or somehow runs multiple
>> threads.   If each processor is entitled to run multiple threads, then
>> there's no reason why the number and structure of cooperating
>> threads should not be dynamically variable.  If you choose to run
>> one thread on each processor, your thread structure is similarly
>> static.  Hardware people have been obliged to think about this
>> kind of thing for decades.  Software people seem to have a
>> pretty good grip on it too, if the textbooks and papers I've read
>> are anything to go by.  Why is it suddenly such a big deal?
>> 
> Not disagreeing with most of what you're saying, but I do feel the need to
> point out the existence of systems with hotpluggable CPUs. Sun and IBM have
> both sold systems for some years where CPUs can be added and removed at
> runtime; software is expected to just cope with this.
> 
> Also in the software domain; there is a cost to switching between different
> threads. Thus, in software, the aim is to limit the number of runnable
> threads to the number of active CPUs. If there are more threads runnable
> than CPUs available, some CPU time is wasted switching between threads,
> which is normally undesirable behaviour.

This is part of the problem.  Parallelism has to be be *inhibited* by
explicit serialisation, to limit the number of threads created.

So a construct like (in Ada):

for I in Truth'Range loop
   Z := Z xor Truth (I);
end loop;

deliberately forces an execution serial order, even although we
know that order does not matter at all, in this case.

There is no effective consruct to permit but not require concurrency.

The software compiler can't sensibly parallelise this because:

The semantics of xor may be unknown (overloaded), and unsuitable
The execution time of each iteration is much smaller than thread
   start/stop time
Too many parallel threads would be created

So we're left with source code which implies a non-existent serialisation
constraint.

If the "for I in all..." construct were in the language, we'd be
able to say "I don't care about the order", and permitting concurrency,
even if the result weren't identical (eg when using floating point)

Numerous algorithms in simulation are "embarrassingly parallel",
but this fact is completely and deliberately obscured from compilers.
Compilers can't normally generated fine-scale threaded code because
the applications don't specify it, the languages don't support it,
and the processors don't need it.  But the technical opportunity
is real.  It won't happen until the deadlock between compilers, software
and processors is broken.
--
Adrian