Re: [9fans] current state of thread programming

[tlaronde@polynum.com]

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) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C