NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/transput/949

Text File | 1992-08-18 | 3.7 KB | 95 lines

Newsgroups: comp.sys.transputer
Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sun4nl!dutrun!dutrun2!dutncp8!rob
From: [e-mail] (Rob Kurver)
Subject: Re: large granularity & going all the way (was: Y should U consider occam?
Message-ID: <rob.714223777@dutncp8>
Sender: [e-mail] (UseNet News System)
Nntp-Posting-Host: dutncp8.tn.tudelft.nl
Organisation: PACT, Delft, The Netherlands
Organization: Delft University of Technology
References: <[e-mail]> <rob.714140217@dutncp8> <[e-mail]>
Date: Wed, 19 Aug 1992 11:29:37 GMT
Lines: 81

In <[e-mail]> [e-mail] (W.G.Day) writes:

>This article is in two parts, both are questions, the former being more of
>a discussion.

>In <[e-mail]> Roger Peel writes:
>Parallel
>enhancements to a sequential language might be acceptable for particularly
>large-grained parallel tasks, too, but this is not where occam stands out,
>either.

>In article <rob.714140217@dutncp8> [e-mail] (Rob Kurver) writes:
>Such function calls don't
>provide the necessary level of abstraction for fine-grain parallelism,
>and often cause an unacceptable overhead.

>In what way isn't occam good at large-grained parallelism?

I don't think either Roger or I were implying that Occam isn't good at
large-grain parallelism, but rather than sequential languages with a
library of parallel support functions hacked on to it aren't very good
at fine-grain parallelism.  For fine-grain parallelism you want to be
able to say something like

    /* PACT Parallel C */        /* Occam [sorry for any typos] */

    par {                PAR
        a = b + c;            a := b + c
        f();        or        f ()
        x = 3;                x := 3
    }

instead of

    /* C with library support */

    void fn1 (void) { a = b + c; }
    void fn3 (void) { x = 3; }
    ...
    Process *p1, *p2, *p3;
    p1 = ProcAlloc (fn1, ...);
    p2 = ProcAlloc (f,   ...);
    p3 = ProcAlloc (fn3, ...);
    ProcPar (p1, p2, p3, NULL);

I think the function approach is OK for large-grain parallelism, where a
program starts but a few threads at the start.  Although a good network
configuration language that allows tasks to be placed and connected seems
a whole lot easier to use even then...

>Rob again:
>This allows fine-grain parallelism to be expressed just as easily as in Occam.

>Does it have the compilation checks too?

It has the normal C compilation checks (channel type etc.), but not
nearly as much as languages like Occam or Pascal.  Many of these checks
become quite impossible in a language that allows modules to be compiled
separately and linked with libraries, and has pointers and the like.
Some checks are done at runtime (stack expansion), and others must be
coded explicitly by the programmer if s/he wants them.  This is all in
the spirit of C, of course, and is considered an advantage by some and
a disadvantage to others.  Just as one chooses between Pascal and C for
sequential programming, one must also decide between Occam and
PACT Parallel C for parallel programming.

As I stated in an earlier message, I don't want to get dragged into a
religious debate about languages, but merely want to point out that
there does exist a Parallel C compiler that provides more than a library
of functions, and allows parallel programs to be written as legibly and
efficiently as Occam.  It does not provide the same level of compile-
time checking as Occam, but does give you structures, recursion, free
format source files and all those other things a lot of people have
got used to since the days of punch-cards.

Rob
--
     PACT                   Rob Kurver
    Foulkeslaan 87         [e-mail]
   2625 RB Delft     ph: [phone]
  The Netherlands   fax: [phone]