The product was absolutely cool and the breakfast spread impressive but I still felt snookered.

There's no question you could set a boatload of breakpoints with a 20-petaflop supercomputer, but you probably need more than that when developing parallelized software for it. You might also resort to fast conditional watchpoints, compiled expressions, asynchronous thread control, and full post-mortem debugging capabilities, and that's just for starters.

If you've been trying figure out what "cloud computing" is, you're not alone -- and coming to the rescue is the National Institute of Standards and Technology. But as nice as the NIST folks are, they didn't have you in mind when they decided to put together an understandable definition of cloud computing.

I'm a sucker for a good pun. (Of course, some would say that there's no such thing as a "good" pun.) So when I came across a paper entitled FAWNdamentally Power-efficient Clusters, I had to read it. And you know what? Not only did I enjoy reading the paper, I actually learned a thing or two about a very important topic.

In wrapping up this year's Intel Software Conference, James Reinders shared a sneak peek of what software developers can look forward to seeing from the company over the coming months, at least in terms of parallel programming tools.

It's little surprise that attendees at this week's Intel HPC Summit in Salzburg, Austria, were more interested in benchmarks than your average group of developers. After all, benchmarking is all about the numbers, and HPC developers tend to be uber-number crunchers.

"Critical sections" are parts of the software for multicore architectures in which only one thread can execute at a given time, causing other threads needing access to shared data to wait for the current thread to complete the critical section.

So you've read the article and watched the video, and you're chomping at the bit to start playing around with Larrabee, Intel's multicore architecture that boasts many cores, many threads, and a new vector instruction set -- all in the name of pushing performance. You have everything you need except -- a Larrabee.

If you're a fan of Seinfeld's Cosmo Kramer, you know there's no better way to start the day than with a good old-fashioned catfight. I don't know that if it rises to that level, but I do think that the OpenMP back-and-forth between Charles Leiserson, coauthor of Introduction to Algorithms and cofounder of Cilk Arts, and Ruud van der Pas, a senior staff engineer at Sun and coauthor of Using OpenMP, makes for some fascinating reading.

"So how are we doing?" James Reinders rhetorically asked a roomful of programmers at SD West 2009 when referring to his Eight Rules for Parallel Programming for Multicore.

Power naps. Now there's something I can relate to. No, not because I get a few minutes of shut-eye in the middle of the afternoon, but because I was just reading about this topic in The Problem of Power Consumption in Servers. The problem, of course, is that data centers are energy hogs, costing money and squander resources.

So you aren't ready to buy into this multicore and parallelization stuff until you're able to see its benefits with your own eyes? If that's the case, then take a couple of minutes to watch this pair of YouTube videos that Gaston Hillar has prepared as part of his book C# 2008 and 2005 Threaded Programming: Beginner's Guide.

It doesn't matter which coffee shop -- Henry's, Z's, or the Bourgeois Pig -- I end up at, it's always the same ever since free WiFi came on the scene. There are more laptops than coffee mugs, and never enough places to sit. But I'm as bad as the rest. What with free wireless Internet access and a cell phone, well, I haven't been in the office for year or so now, and even the concept of a home-office is becoming more remote.

Wouldn't you know it. Just as we're starting to wrap our minds around the idea of parallel programming and multicore processors, Intel ups the ante with Larrabee, a many-core architecture that has the potential to change the game. This doesn't mean that the concepts of multithreading and parallel programming can be ignored. Quite the contrary. If anything, thinking parallel and having a firm grasp on multithreading will be more critical than ever -- especially if you intend on tackling Larrabee.

Just because the term "cloud computing" has been ridden hard and put away wet doesn't mean there isn't any "there" there. Hype aside, cloud computing appears to be for real. The promise that cloud computing offers developers with great ideas but little cash execute those ideas is reason enough to hop on the bandwagon.

Every now and then one of those don't-miss workshops pops up. Alas, I usually don't make it to them because the boss and I have a different definition of what "don't miss" means. But we see eye-to-eye on the upcoming Workshop on Directions in Multicore Programming Education to be held on March 8, 2009, in Washington DC. When I told him about it, the boss said "Sounds great. What time does your bus leave?" Hmmm, California to DC on a Greyhound bus for an 8-hour workshop? Darn, sounds like another great event I'll miss. But that doesn't mean you have to miss it, particularly if you're in the neighborhood.

There's not much good that we can say when it comes to the economy. Still, there are those among us who see the bottle half full, rather than half empty.

Now I know why Dr. Dobb's columnist and concurrency expert Herb Sutter hasn't turned in his column -- he's been preparing for his upcoming Effective Concurrency seminar on March 16-18, 2009 in Stockholm, Sweden.

The goal of PetraVM, a startup launched by University of Washington computer science professors Mark Oskin and Luis Ceze, is to develop technology for writing more reliable multi-threaded code for multi-core architectures.

James Reinders, author of Intel Threading Building Blocks: Outfitting C++ for Multi-core Processors, recently took a few minutes to talk about going parallel.

Q: James, are software developers ready for parallelization, or are we lacking the fundamental building blocks -- parallel algorithms, compilers, tools, and the like -- needed to effectively build concurrent applications?

You can always tell when the developers roll out something before marketing has a crack at "preparing" it. And that ususally starts with the name of the product or the title of the paper. Take, for instance, the programming model for graphics pipelines created and described a team of researchers from Stanford University and Microsoft Research.

I don't know about you, but I'm stoked about the Super Bowl. No, I haven't stocked up on chips, queso dip, and beer. Heck, I'm not even much of a pro football fan. But with the news that Dreamworks Animation, Intel, Pepsi, and NBC are planning a big 3-D movie promotion around the Super Bowl, I didn't waste any time dusting off the 3-D glasses that Intel and Dreamworks Animation handed out at the Intel Developer's Forum last August.

It's been said more than once that parallel programming is hard, which suggests that the sooner you get a jump on concurrency, the better off you'll be. So when and how should programmers be introduced to parallalism?

The goal of the Universal Parallel Computing Research Center at the University of Illinois at Urbana-Champaign (UPCRC) is to make client parallel programming synonymous with programming. To that end, their key themes are a transformative change from current low-level bug-prone programming models to a disciplined parallel programming ecosystem, and a broad-based attack on parallelism at all levels of the stack that focuses on enabling performance, scalability, and support for programmability. For a complete and most interesting discussion of how UPCRC tackles parallel programming, see Parallel@Illinois: Pioneering and Promoting Parallel Computing.