Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Mark Leighton Fisher (4252)

Mark Leighton Fisher
  (email not shown publicly)
http://mark-fisher.home.mindspring.com/

I am a Systems Engineer at Regenstrief Institute [regenstrief.org]. I also own Fisher's Creek Consulting [comcast.net].
Friday April 13, 2007
11:57 AM

The Free Lunch is Over, and Other Thoughts on Concurrency

[ #32984 ]

I wouldn't go as far as the author of The Free Lunch is Over: A Fundamental Turn Toward Concurrency in Software, but (IMHO) much of the current growth in processing speeds has been the result of harnessing the parallel processing of cheap COTS computers Google, for example. Multi-core CPUs look like a similar phenomenon.

Further thoughts: It looks to me as if concurrency is like every other development paradigm simpler is better. To me, this means:

  • Shared-nothing memory (i.e. explicit sharing via message passing) will provide the way forward when threads need to share data, as it requires tracking fewer interactions; and
  • Some perhaps much of the gains from increased concurrency will occur because of the concurrency encapsulated in libraries.

As an example of encapsulated concurrency, off-loading printing to another thread (from the viewpoint of the caller) is mostly a matter of handing the contents of the page off to a subroutine no further interaction with the print routine is necessary once the data has been prepared.

From where I'm sitting, there's a significant difference between threads that must continue interacting with each other as compared to threads that each go their merry way once the threads have been created. This second case of threading, with the threads (at least mostly) independent after their creation is amenable to encapsulation and encapsulated code (including encapsulated threaded code) is easier to deal with. We mortals are equipped to mentally deal with only a limited number of "things" at one time, so encapsulating threaded behavior is a Good Thing.

I'm just musing here, but there may also be gains to be had from letting programs perform more actions in the background, with appropriate caching of the results for later use. (The Caching and Memoization chapter in Higher-Order Perl has influenced my thinking lately.)

At least for a while, common processing power gains will come from an increased number of CPU cores rather than faster CPU cores, so we software engineers need to prepare ourselves for this phase of computing.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.