"Robbert Haarman" <comp.lang.misc@[EMAIL PROTECTED]
> wrote in message
news:20071219050459.GA4148@[EMAIL PROTECTED]
> 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 circumstances.
>
> Just my two cents.
>
problem with this approach:
it may be problematic to determine at compile time (one would at least
need
things like profiler output, ... to be able to determine this, but this
could be possible with a VM-like compiler framework).
to determine this at runtime would add too much overhead to program
execution.
some of us actually want parallelism and concurrency, not for reasons of
performance, but because it can be a useful programming construct.
now, my idea had been, ideally, that the number of threads would be
essentially unknown, rather, there would be 'hard' threads (representing
actual system/OS threads) and 'soft' threads (a programming concept of
threads, likely consisting of little disconnected pieces of code running
through a work queue and being executed by some number of worker threads).
sadly, most existing compiler machinery and language semantics make this
later option (soft threads) problematic.
within normal C, each thread would need, at least, its own stack. however,
we could make each such stack fairly small, and thus specify that it is
not
safe for code executing within such soft threads, to do certain things
(for
example, overly recursive code, or using too much memory for stack-based
variables).
for example, what if each such thread has only 16 or 64kB of stack
space?...
it is a possible option at least I guess...
> Bob
>
> --
> ``Those who forget history are doomed to repeat it.''
>
|
