Springing out of the ashes (and a job where I have to write Java) for my
first post in years:

On Fri, 04 Jan 2008 13:13:11 -0800, Dave Whipp <[EMAIL PROTECTED]> wrote:
> I agree that adding a parallel "forall" (and similar statements) via a
> pragma will be easy if the appropriate underlying machinery is there, so
> maybe I can live with the bias in S04 -- perhaps rename it to
> "Sequential Blocks and Statements". Anywhere that we guarantee
> sequential behavior, we pretty much rule out concurrency. But if we
> maximize the number of places where we are explicitly "unordered" then
> we also maximize the number of places where implicit concurrency can be
> added later. From that perspective, it's unfortunate a C<for> loop
> always iterates arrays in the order of their indices.

I wouldn't agree with that at all. I think of arrays as ordered constructs,
so I'd want the default iteration over my array to happen in the order of
the indices. I wouldn't have a problem with having the ability for C<for>
to iterate over a bag or some other inherently unordered, unsorted
container in arbitrary possibly-parallel order though. Possibly by default,
if the compiler can be satisfied that the closure's not got any unpleasant
side effects to interfere with parallel execution.

I think you're leaning too far towards concurrency in attempting to address
the perceived bias. A lot of the time, the compiler's not going to be able
to prove that it's safe to autothread a given closure because it might have
side effects. If we were talking about Haskell or some other language which
is ordinarily pure, things would be different. Under these circumstances, I
would much rather have to explicitly say that I want parallel execution -
provided that the ability to do it is there and it's easy to get at and
behaves in a sensible manner (naturally this lets you parallelise things
the compiler isn't sure are safe to parallelise due to possible side
effects. That's fine, since you know which side effects are okay to do that
to in your program).

Matthew

Reply via email to