Danielle Fong | 7 Jul 00:11

Re: Parallel vs. sequential loops

the only parallel construct that has been discussed here so far will silently introduce
catastrophic performance degradation into user code when they least expect it.

Isn't that a little premature? On the other hand, I would like some pointers to Jan's design work. This part really fascinates me but it seems very complex.

On Sun, Jul 6, 2008 at 2:29 PM, Jon Harrop <jon-gOjbu7hk+9q6HovDotTUrQC/G2K4zDHf@public.gmane.org> wrote:
On Saturday 05 July 2008 17:07:06 David Chase wrote:
> You should know, that a large amount of work (most of it Jan's, but
> distributed onto the rest of the team as he generates interpreter and
> type-system problems along the way) has been devoted to the design of
> "generators", so that when you write the so-called "naive parallel for
> loop" what you get is in fact, recursive subdivision, preferably with
> the subdivision chosen to be "best" for the data that is driving the
> parallelism.

Exactly. The "best" subdivision must be guided by cost information and these
naive parallel "for" loops fail to convey any such information. So the
subdivision is completely naive and, consequently, the only parallel
construct that has been discussed here so far will silently introduce
catastrophic performance degradation into user code when they least expect
it.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e



--
Danielle Fong (.com)
415-508-6732

Gmane