On Wed, Dec 19, 2007 at 07:54:44AM +1000, cr88192 wrote:
>
> or, more explicit (one of my original syntax ideas):
> int fib (int n)
> {
> if (n < 2) return n;
> else
> {
> int async x, y;
>
> x = fib!(n-1);
> y = fib!(n-2);
>
> return (join(x)+join(y)); //one possibility
> return ($x+$y); //'$' being used as a join
operator
> (gcc conflict)
> return (x+y); //semanics: 'async' vars are
always
> synced before operators
> }
> }
Or, since the compiler can infer (not necessarily in this language, but
it's easy to design a language in which it can) that fib does not depend
on state (i.e. will give the same results no matter the order of
evaluation)
int fib (int n)
{
if (n < 2) return n;
else
{
int x, y;
x = fib(n-1);
y = fib(n-2);
return (x+y);
}
}
...and the runtime will run the recursive invocations of fib in seperate
threads if and when this is beneficial (as determined by some heuristic,
most likely).
This means that:
1. The programmer does not have to write any extra code to get
parallelism.
2. The programmer does not have to decide how many threads there will
be.
3. The programmer does not have to think about concurrency at all.
4. The number of threads will (given a good heuristic) be close to the
optimal number, given the run time cir***stances.
Just my two cents.
Bob
--
``Those who forget history are doomed to repeat it.''
|
