From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <9ab217670903031554g24339eedmd68f20809173329d@mail.gmail.com>
References: <138575260903030352s623807d7p5a3075b1f7a591f6@mail.gmail.com>
	<3e1162e60903030719v141b41e9ma5fd98c73d8b0e7c@mail.gmail.com>
	<1236103870.4929.101.camel@goose.sun.com>
	<3aaafc130903031508v5e4b3d96n2b53677049e086f6@mail.gmail.com>
	<5d375e920903031515x7b25dc5hd1ced6d098bd02d0@mail.gmail.com>
	<3aaafc130903031523h1be94cf1ta61e01fd0caab10e@mail.gmail.com>
	<9ab217670903031554g24339eedmd68f20809173329d@mail.gmail.com>
Date: Tue,  3 Mar 2009 19:33:33 -0500
Message-ID: <3aaafc130903031633n19ce8800ma5eeee44886bed52@mail.gmail.com>
From: "J.R. Mauro" <jrm8005@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] threads vs forks
Topicbox-Message-UUID: ae72062e-ead4-11e9-9d60-3106f5b1d025

On Tue, Mar 3, 2009 at 6:54 PM, Devon H. O'Dell <devon.odell@gmail.com> wrote:
> 2009/3/3 J.R. Mauro <jrm8005@gmail.com>:
>> Concurrency seems to be one of those things that's "too hard" for
>> everyone, and I don't buy it. There's no reason it needs to be as hard
>> as it is.
>
> That's a fact. If you have access to The ACM Queue, check out
> p16-cantrill-concurrency.pdf (Cantrill and Bonwich on concurrency).

Things like TBB and other libraries to automagically scale up repeated
operations into parallelized ones help alleviate the problems with
getting parallelization to work. They're ugly, they only address
narrow problem sets, but they're attempts at solutions. And if you
look at languages like LISP and Erlang, you're definitely left with a
feeling that parallelization is being treated as harder than it is.

I'm not saying it isn't hard, just that there are a lot of people who
seem to be throwing up their hands over it. I suppose I should stop
reading their material.

>
>> And nevermind the fact that it's not really usable for every (or even
>> most) jobs out there. But Intel is pushing it, so that's where we have
>> to go, I suppose.
>
> That's simply not true. In my world (server software and networking),
> most tasks can be improved by utilizing concurrent programming
> paradigms. Even in user interfaces, these are useful. For mathematics,
> there's simply no question that making use of concurrent algorithms is
> a win. In fact, I can't think of a single case in which doing two
> lines of work at once isn't better than doing one at a time, assuming
> that accuracy is maintained in the result.

I should have qualified. I mean *massive* parallelization when applied
to "average" use cases. I don't think it's totally unusable (I
complain about synchronous I/O on my phone every day), but it's being
pushed as a panacea, and that is what I think is wrong. Don Knuth
holds this opinion, but I think he's mostly alone on that,
unfortunately.

Of course for mathematically intensive and large-scale operations, the
more parallel you can make things the better.

>
> --dho
>
>