From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 30 Jul 2008 19:31:56 +0200 From: tlaronde@polynum.com To: erik quanstrom , 9fans@9fans.net Message-ID: <20080730173156.GA484@polynum.com> References: <9b1933b61c606e89a4cbbc93a4b5a204@quanstro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b1933b61c606e89a4cbbc93a4b5a204@quanstro.net> User-Agent: Mutt/1.4.2.3i Subject: Re: [9fans] current state of thread programming Topicbox-Message-UUID: f69af9ac-ead3-11e9-9d60-3106f5b1d025 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