Parallel programming is the focus of increasing interest | Hacker News Reader

Parallel programming is the focus of increasing interest

economist.com

87 pointscoolpixar19 comments

When I read an article in the Economist about some topic I know a lot about I tend to finish feeling that they've oversimplified a bit. When I read an article elsewhere in the mainstream media about some topic I know a lot about I tend to finish feeling that the reporter had no idea what they were talking about.

That's why I have a print subscription to the Economist.

I only subscribe to one periodical, and it's the Economist. I even get most of my news from there, even if it's a few days old by the time I get to it, because if it's important enough to read about, it won't matter if it's a bit old.

I have the same attitude about the Economist and the New Yorker. Indeed, it's amazing how many of the really big stories of the last few years have broken in the New Yorker, a magazine that gives its reporters months to write stories.

Same here. Only print subscription I retain at this point. FT would be a close second if not for the fact that their website is beyond terrible.

The Economist: one of the few old-school journalism enterprises not to make its way forward by appealing to the lowest common denominator of the potential audience. They go for a smaller audience but can focus much more tightly on what that audience wants: smart, concise explanations of serious issues.

"“We’re not going to have faster processors,” says Katherine Yelick, a computer scientist at the Lawrence Berkeley National Laboratory in California."

Seems a little premature, I wouldn't rule out some big leap forward in processor technology. Very good article though.

What factors do you think might lead to a "big leap forward in processor technology"?

And appropriately enough the last article published under the topic 'Programming Languages' was published on Apr 3rd 2003.

Why is this so surprising? The Economist, like the New Yorker, is famed for its great journalism that covers very wide areas, much wider than Economics, in the case of the former, or the current events in New York, for the latter.

IEEE Software Vol 28 Issue 1 covers Parallelism on the Desktop-

http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=567250...

They even have an article about Intel Threading Building Blocks -

http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2...

Threading Building Blocks is open source C++ and can be found here-

http://threadingbuildingblocks.org

One thing that might help is moving away from event loop based UI interaction, like we see in Windows. One effort in this direction was http://en.wikipedia.org/wiki/BeOS.

Do you have any info about how BeOS moves away from the event loop?

http://en.wikipedia.org/wiki/Haiku_(operating_system) seems to have a fair amount of docs on how their API works. Since it is an open source implementation of BeOS it might have some good information. BeOS was made with SMP in mind from word one.

I'm having a hard time guessing the details of how a GUI that doesn't have an event loop in it would work, so I think a more detailed answer would be very interesting.

It is shocking the absence of any mention of OpenCL in the article.

OpenCL could be used either for task parallel(for serial programs and multiple CPUs) or for data parallel(GPUs), and it works really well.

I bet it has more money behind from Apple, Intel, AMD and NVIDIA that ten times whatever MS has invested. (And those companies are hardware companies and know what they are doing).

It's not just new languages, it's new algorithms, most problems aren't trivially parallel.

The problems that are trivially parallel are well suited to be solved by functional/reactive programming via languages like Haskell, Erlang, Scala, F# and Ocaml.

"Functional/reactive" has a very specific meaning, unrelated to parallelism.

I'm aware of the differences but writing your code in a functional / reactive style makes parallelism much easier.

List.map can be safely parallelized in a functional language where as it cannot in an imperative language. That's what I'm getting at.

In a functional language (lets say haskell) you could switch the implementation of map to a parallel one and the community would probably accept it because there are a few edge cases involving doing something with a monad where it would break but 99% of code would work. If you did the same thing in Java/C/C++/C#/Python/Ruby it would break massive amounts of code.

In theory they have absolutely nothing to do with each other, but in practice they have a lot to do with each other.

The edge cases would involve unsafePerformIO - you can't use map with functions in a monad, that's what you have mapM for :)

Reply on news.ycombinator.com