Re: [9fans] current state of thread programming - Plan9

This is a discussion on Re: [9fans] current state of thread programming - Plan9 ; On Wed, Jul 30, 2008 at 08:50:28AM -0400, erik quanstrom wrote: > > i don't see how csp is *not* parallel processing. as soon > as you have more than 1 work process per client, i would call > that ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: [9fans] current state of thread programming

  1. Re: [9fans] current state of thread programming

    On Wed, Jul 30, 2008 at 08:50:28AM -0400, erik quanstrom wrote:
    >
    > i don't see how csp is *not* parallel processing. as soon
    > as you have more than 1 work process per client, i would call
    > that parallel processing.


    It's a kind of parallelism, of course. But since it makes sense, it is
    not "parallelism" as the trend is today

    > [..]
    > one could argue that isn't *really* parallel because the
    > requests for the n blocks are made sequentially.
    > but since drives, operating on the timescale of tens of
    > milliseconds are competing with a processor working on
    > a nanosecond timescale. that's effectively "all at once".


    This is precisely the point:

    1) It is not "pure parallelism" or "parallelism du jour". But it is parallelism
    too.

    2) Developers have not waited for the trend to make or use parallelism.

    3) An algorithm is, for me, intrinsically sequential (the elementary
    unit is sequential). Parallelism is more at a higher level: methodology,
    engineering, the same level as, say, structural programming.
    --
    Thierry Laronde (Alceste)
    http://www.kergis.com/
    Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C


  2. Re: [9fans] current state of thread programming

    >> i don't see how csp is *not* parallel processing. as soon
    >> as you have more than 1 work process per client, i would call
    >> that parallel processing.

    >
    > It's a kind of parallelism, of course. But since it makes sense, it is
    > not "parallelism" as the trend is today


    I don't know what the trend is today. If the trend is defined by what
    Linux does then I'm not very curious.


    The point of the Plan 9 thread library was — and still is, as far
    as I'm concerned — to be a tool that aids in concurrent programming.
    I'm explicitly not saying parallel programming. I think of
    parallel programming as a technique for finishing some algorithm faster.
    I think of concurrent programming as a way of keeping indeterminism
    under control. A file server serves many customers simultaneously,
    and must expect requests, disk events, etc. to happen in any order.

    Managing this is what Plan 9 threaded programs are good at.
    And our model of using channels for interthread and interprocess
    communication, while using a thread pool (all in one proc) for managing
    shared data without needing locks, is the best programming model for
    these kinds of programs I've ever come across.

    You can write parallel programs using the thread library but that's not
    what its primary purpose was and it's probably not going to help you
    much.

    Sape



  3. Re: [9fans] current state of thread programming

    On Wed, Jul 30, 2008 at 02:58:48PM -0400, Sape Mullender wrote:
    > >
    > > It's a kind of parallelism, of course. But since it makes sense, it is
    > > not "parallelism" as the trend is today

    >
    > I don't know what the trend is today. If the trend is defined by what
    > Linux does then I'm not very curious.


    Since my pseudo-english is only what it is, I hope that "kind of
    parallelism" is not interpreted pejoratively. I mean a "form of
    parallelism", a "way of using parallelism", etc.

    >
    > I think of parallel programming as a technique for finishing some algorithm faster.
    >


    I do agree with what you wrote and emphasize particularily this
    sentence : parallelism doesn't _solve_ a problem; it delivers
    the solution sooner. That's why I'm saying that an algorithm (that is
    the expression of a solution) is sequential. But organization can be
    parallel.

    But indeed CSP is also a solution (above concurrency/"parallelism") to
    solve a kind of problems. It is not mere parallelism, it is a way of
    using/dealing with concurrency (a form of parallelism).


    Real world example (about "parallelism", not CSP): geometrical
    application, vectorial data, transforming "spaghettis" into
    topologically correct data (connected edges). I had debugged an
    existing program. It was finally giving an acceptable result, but
    it was not scalable.

    The "trend" today would be: convert to "threads" to go faster.

    But the problem was not to parallelize a poor algorithm. The problem was
    to find the correct data structure and "sequential" algorithm for this
    data and its manipulations.

    It happens that once these are found (or at least better ones),
    the program could be naturally parallelized (even simply by splitting
    the data into chunks; running distinct processes on the distinct
    chunks; and concatenating the results). Parallelism is a by-product. It
    was not a goal. And it simply can transform a program taking n *
    some_unit_of_time, in a program taking something near 1 some_unit_of_time
    given n cores. But the main gain was the big O of the sequential
    algorithm.

    A better algorithm improves the solution or the delivery of the solution
    on a single CPU. Parallelization doesn't improve the solution or the
    delivery of a solution on a single CPU (it may even worsen the times).

    Cheers,
    --
    Thierry Laronde (Alceste)
    http://www.kergis.com/
    Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C


+ Reply to Thread