From mboxrd@z Thu Jan 1 00:00:00 1970 From: tlaronde@polynum.com Date: Wed, 30 Jul 2008 22:04:06 +0200 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20080730200406.GA3823@polynum.com> References: <20080730173156.GA484@polynum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: [9fans] current state of thread programming Topicbox-Message-UUID: f7564888-ead3-11e9-9d60-3106f5b1d025 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