Why so little parallelism?
|
From: Eric P. on 16 Jan 2007 10:57 Peter \"Firefly\" Lund wrote: > > On Mon, 15 Jan 2007, Eric P. wrote: > > > This sounds like another in the long line of Wish Based Technologies > > (not that this has stopped anybody in the past). > > Did you read any of the previous articles on STM? > > I can recommend "Composable memory transactions": > > http://research.microsoft.com/~simonpj/papers/stm/index.htm > > (Actually, I can recommend *anything* by Simon Peyton Jones, no matter the > subject. Take a look at his article on Excel, functions, and usability.) > > -Peter Yeah, I have been reading about it off and on for quite some time, though I don't specifically recall reading anything from Microsoft. While the basic idea is interesting, the example applications are trivial, there are no comparative analysis to support claims of superiority, and yet is peddled as the latest panacea solution that allows mediocre programmers to write complex parallel systems. If you look at some of the examples, you should be able to anticipate the problems their (expensive and slow) collision-undo-retry approach will encounter, yet this is supposed to work for naive programmers? I don't think so. And I doubt the Haskell programming language is going to take over the world any time soon. Eric
From: "Peter "Firefly" Lund" on 16 Jan 2007 12:48 On Tue, 16 Jan 2007, Eric P. wrote: > that allows mediocre programmers to write complex parallel systems. But it does. Modules that use parallel code becomes composable. > If you look at some of the examples, you should be able to anticipate > the problems their (expensive and slow) collision-undo-retry approach It doesn't have to be collision-undo-retry; that's just because they are still prototyping things (and they are probably more interested in software engineering and maybe in hardware primitives). The evaluation order for things that do not have side effects is free in Haskel. Playing with different evaluation strategies is something they already do -- optimistic evaluation for things that are deemed to be likely to be needed is a recent example. > will encounter, yet this is supposed to work for naive programmers? > I don't think so. And I doubt the Haskell programming language is > going to take over the world any time soon. Of course it won't :) Haskel-- and functional programming in general -- has been a supplier of good ideas for mainstream imperative languages for some time. If this works well enough it'll probably end up in C#. -Peter
From: Nick Maclaren on 16 Jan 2007 13:12 In article <Pine.LNX.4.61.0701161842090.31465(a)ask.diku.dk>, "Peter \"Firefly\" Lund" <firefly(a)diku.dk> writes: |> |> Haskel-- and functional programming in general -- has been a supplier of |> good ideas for mainstream imperative languages for some time. If |> this works well enough it'll probably end up in C#. It was before my time, but I think that LISP gave some ideas to Algol 60, and certainly did to Algol 68 :-) Regards, Nick Maclaren.
From: Nicholas King on 16 Jan 2007 21:52 Nick Maclaren wrote: > If that is so, it will be much easier for ordinary programmers > to write simple code, but will not help much with complex code, and it > will be essentially untunable. So essentially it will be solving a problem that didn't need to be solved? Sounds awfully useless to me. There is no magic way of making complex things simple. The sooner we start properly educating the programmers the better instead of looking for quick fix solutions and accepting mediocrity. Nicholas King
From: Del Cecchi on 16 Jan 2007 23:25
"Nicholas King" <zeddie(a)internode.on.net> wrote in message news:12qr3rpluieia99(a)corp.supernews.com... > Nick Maclaren wrote: >> If that is so, it will be much easier for ordinary programmers >> to write simple code, but will not help much with complex code, and it >> will be essentially untunable. > So essentially it will be solving a problem that didn't need to be > solved? > > Sounds awfully useless to me. There is no magic way of making complex > things simple. The sooner we start properly educating the programmers > the better instead of looking for quick fix solutions and accepting > mediocrity. > > Nicholas King Of course there are ways, although I don't know if they are magic, of making complex things simple. We use calculators to take cube roots. Ever do one longhand? Got a book of log tables? We use verilog and vhdl to model and synthesize logic designs. Can you imagine designing a million gate chip coding nands and nors in the netlist by hand, like we did it in the old days of BDL/S (internal IBM netlist language)? Writing operating system in assembler? Writing windowing programs without a canned GUI thing like xwindows? I could go on for a considerable time. The only way to get past complex problems is to get above them and hide them. del |