Monday, February 14, 2005

A pressure for concurrency

Herb Sutter published an article called The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software. It's a fascinating reading in which he argues we (the programmers) are now facing the next major paradigm shift since introduction of object-oriented programming. The reason?
Applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains.
And this is caused by the new hardware trend towards multicore systems, in contrast with CPU clock speed wars we had till recently.

IMO, a need for concurrent progaramming would impact mostly the "high" end of the programmers spectrum: system programming (OS, RDBMS, Web servers, game engines, etc.) and library authors. For many (most?) end-user application the execution speed is not crucial for a long time.

PS: It will be interesting to watch out how tooling vendors react to this trend. For instance, CPython has an infamous GIL which looks like a real obstacle for Python programs on multicore systems.

3 Comments:

Blogger Bob Ippolito said...

[from a post I made on the same topic when discussed last on python-dev]

Wouldn't it be nicer to have a facility that let you send messages
between processes and manage concurrency properly instead? You'll need
most of this anyway to do multithreading sanely, and the benefit to the
multiple process model is that you can scale to multiple machines, not
just processors. For brokering data between processes on the same
machine, you can use mapped memory if you can't afford to copy it
around, which gives you basically all the benefits of threads with
fewer pitfalls.

11:45 PM  
Blogger Max Ischenko said...

Point taken.

Still, there are plenty of patterns on concurrency, Herb Sutter mentions that. Just like in OO - each has it's own tradeoffs.

8:24 AM  
Anonymous Nicolas Lehuen said...

I've just finished a book about Erlang. It's a pretty interesting language to learn in this context, with its message passing architecture.

Erlang benefits from its functional programming style, meaning that you don't have to worry about concurrent side effects and the mayhem that could ensue.

The problem is that functional programming still feels a bit weird to me, so an equivalent message passing mechanism in a procedural language could be examined. Time to have a deeper look at Spread [http://www.spread.org/]...

10:12 PM  

Post a Comment

<< Home