How Many Processor Cores Are Enough?
|
From: Chris Thomasson on 21 Nov 2006 01:49 "Brian Hurt" <bhurt(a)spnz.org> wrote in message news:e0t8h.7975$lq.2268(a)newsread1.mlpsca01.us.to.verio.net... > nmm1(a)cus.cam.ac.uk (Nick Maclaren) writes: > > >>That experience debunked the claims of the >>functional programming brigade that such methodology gave automatic >>parallelisation. > > Automatic parallelization, no. You're looking for a silver bullet that > probably doesn't exist. On the other hand, functional programming makes > writting parallel code much easier to do. > > The biggest problem with parallelized code is the race condition- which > arise from mutable data. Every peice of mutable data is a race condition > waiting to happen. Mutable data needs to be kept to an absolute minimum, > and then handled in such a way that it's correct in the presence of > threads. > > I've come to the conclusion that functional programming is necessary- > just not sufficient. http://groups.google.com/group/comp.programming.threads/browse_frm/thread/b192c5ffe9b47926 Your conclusion is wrong. No need to be afraid of mutable data... Just stick it all in the writer side of a lock-free reader pattern. > There are two languages I know of in which it may > be possible to write non-trivial parallel programs correctly and > maintainably- concurrent haskell with STM and erlang- and both are, at > their core, purely functional languages. STM is a no go. Way too much overhead... Here are some of the reasons why: http://groups.google.com/group/comp.arch/msg/e1e391055c7acecb http://groups.google.com/group/comp.programming.threads/browse_frm/thread/9c572b709248ae64 http://groups.google.com/group/comp.programming.threads/browse_frm/thread/f6399b3b837b0a40 http://groups.google.com/group/comp.arch/msg/1b9e405080e93149 http://groups.google.com/group/comp.arch/msg/bbbc035cf1a8502c http://groups.google.com/group/comp.arch/msg/11b14c4bda2d5d82 http://groups.google.com/group/comp.arch/msg/9b00fda2752966f9 http://groups.google.com/group/comp.arch/msg/335aeb22fd6fe526 http://groups.google.com/group/comp.arch/msg/1ace9400b1b16cd4 http://groups.google.com/group/comp.arch/msg/995379a16beb3b69 (simply excellent Wheeler post) .... Any thoughts? ;^)
From: Nick Maclaren on 21 Nov 2006 04:26 In article <e0t8h.7975$lq.2268(a)newsread1.mlpsca01.us.to.verio.net>, Brian Hurt <bhurt(a)spnz.org> writes: |> nmm1(a)cus.cam.ac.uk (Nick Maclaren) writes: |> |> >That experience debunked the claims of the |> >functional programming brigade that such methodology gave automatic |> >parallelisation. |> |> Automatic parallelization, no. You're looking for a silver bullet that |> probably doesn't exist. On the other hand, functional programming makes |> writting parallel code much easier to do. Oh, no, I am not! I pointed out to those idiots at the time that silver bullets didn't work, but there is no arguing with religious fanatics :-( While using functional code to express functional concepts is good for many reasons, contorting stateful designs into a functional style makes them much HARDER to parallelise, by obscuring their design. |> The biggest problem with parallelized code is the race condition- which |> arise from mutable data. Every peice of mutable data is a race condition |> waiting to happen. Mutable data needs to be kept to an absolute minimum, |> and then handled in such a way that it's correct in the presence of |> threads. Sorry, no. That may be the biggest LOW-LEVEL problem, but there are much worse ones :-( |> I've come to the conclusion that functional programming is necessary- |> just not sufficient. There are two languages I know of in which it may |> be possible to write non-trivial parallel programs correctly and |> maintainably- concurrent haskell with STM and erlang- and both are, at |> their core, purely functional languages. I have come to the conclusion that it isn't even desirable - but that needs qualification. I fully agree that functional programming should be the first port of call. If your code can be expressed naturally in pure functional terms, then that should be done - and NOT just for parallelism! We are in absolute agreement there. It's when it can't that the problem arises. Replacing iteration by recursion with assumed tail removal is a neat idea that doesn't work; it ends up being equivalent in all respects, problems and all. Regards, Nick Maclaren.
From: Joe Seigh on 21 Nov 2006 11:13 Nick Maclaren wrote: > In article <e0t8h.7975$lq.2268(a)newsread1.mlpsca01.us.to.verio.net>, > Brian Hurt <bhurt(a)spnz.org> writes: > |> nmm1(a)cus.cam.ac.uk (Nick Maclaren) writes: > |> > |> >That experience debunked the claims of the > |> >functional programming brigade that such methodology gave automatic > |> >parallelisation. > |> > |> Automatic parallelization, no. You're looking for a silver bullet that > |> probably doesn't exist. On the other hand, functional programming makes > |> writting parallel code much easier to do. > > Oh, no, I am not! I pointed out to those idiots at the time that silver > bullets didn't work, but there is no arguing with religious fanatics :-( > > While using functional code to express functional concepts is good for > many reasons, contorting stateful designs into a functional style makes > them much HARDER to parallelise, by obscuring their design. > I think the attraction of functional programming is composability. I think there might be a way to get composability in procedural languages but it's so far out of my areas of expertise that I think I'll wait for someone else to figure it out. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.
From: Nick Maclaren on 21 Nov 2006 11:34 In article <dLGdnRGBz8Rjuf7YnZ2dnUVZ_qednZ2d(a)comcast.com>, Joe Seigh <jseigh_01(a)xemaps.com> writes: |> |> I think the attraction of functional programming is composability. I think |> there might be a way to get composability in procedural languages but it's |> so far out of my areas of expertise that I think I'll wait for someone else |> to figure it out. You can write functional code in Fortran, and dysfunctional code in Haskell :-) At a higher level, functional programming AS SUCH gains little; if you have to pass damn great structures which you keep changing for subsequent calls and have to recurse many thousands of levels deep, just to avoid an iteration with global variables, you have gained nothing. It is a functional DESIGN that helps with composability. Regards, Nick Maclaren.
From: Joe Seigh on 21 Nov 2006 11:59
Nick Maclaren wrote: > In article <dLGdnRGBz8Rjuf7YnZ2dnUVZ_qednZ2d(a)comcast.com>, > Joe Seigh <jseigh_01(a)xemaps.com> writes: > |> > |> I think the attraction of functional programming is composability. I think > |> there might be a way to get composability in procedural languages but it's > |> so far out of my areas of expertise that I think I'll wait for someone else > |> to figure it out. > > You can write functional code in Fortran, and dysfunctional code in > Haskell :-) > > At a higher level, functional programming AS SUCH gains little; if > you have to pass damn great structures which you keep changing for > subsequent calls and have to recurse many thousands of levels deep, > just to avoid an iteration with global variables, you have gained > nothing. It is a functional DESIGN that helps with composability. > Nothing like that. But I'll just concentrate on solving unsolvable problems in the areas I do know about. Not that solving them does any good. :) -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. |