I jotted out a note: "Memo to self: The fastest way to unemployment is to not hone my programming skills for exploiting parallelism." Originally I was going to say, "Memo to software developers." Then I realized I was just avoiding the truth—this was a memo to me. I have some experience in this area already, and I may be ahead of the curve, but the rush to multi-core is hardly going to slow down to match my speed.

Multi-core changes the world. For software developers, multi-core is both an opportunity and a headache for software developers.

Why have we waited so long to move to parallelism? Simple—it is a change we've been able to avoid—one which requires us to think and act differently.

What benefits does it have? I think of it this way—you can have all the performance you want if your program is ready for parallelism. All you have to do is buy more processor cores. You no longer have to wait for Moore's law to double your performance every 18 months. Instead, just buy more processor cores. Of course, you can wait for double the cores at the same price—and get the benefits for free as time marches on. You need to think and program "parallel" for this to be real.

Do we have a choice? Not really, but that doesn't mean it is bad. In fact, I'm quite convinced that the "not parallel" era will appear to be a very primitive time in the history of computers when people look back in a hundred years. The world works in parallel, it is about time for computer programs to do the same.

The exciting new software development products we introduced in August are unique in how they solve key problems others are not solving. They make the developers' work significantly easier. Updates to two of our great tools—Intel Thread Checker and Intel Thread Profiler—and a really important new product that extends C++ for parallelism—the Intel Threading Building Blocks—will make it much easier for developers to realize significant gains with each new processor innovation.

At Intel, we have been doing multiprocessor work for years and are arguably the best in the world at producing and debugging multiprocessor code. Now everyone needs to care. And with these new tools, we have solutions to help.

We all have things to learn. But the day is not far off when we will entertain a younger generation of developers with hair-raising tales of how we optimized instructions to speed up the one thread of execution we had available to us. We will tell our tales, and they will be interesting history because no one will be thinking that way anymore.

Within a decade, a programmer who does not think "parallel" first will not be a programmer. Programming in parallel is not intrinsically harder than what we do now, but it is different. We need to think differently, and we need tools that support this thinking. The tools in this new world do not need to be radically different—but they need to address key problems related to abstraction of thread management and correctness verification.

Decades ago programmers looked to high-level languages to abstract machines so that Fortran, COBOL and C could replace assembly language programming. In time, abstraction grew to include C++, Java and C# to name a few. Now, we need to avoid thinking that parallelism is exploited through Windows threads and pthreads. Instead, we need to look to OpenMP and Intel Threading Building Blocks.

Also, we need to acknowledge the new challenges in debugging threaded applications. Specifically, we need to eliminate potentials for data races and deadlock. This is why the Intel Thread Checker is so exciting—it is a tool to help developers do exactly that. We have learned a lot since version 1, so our version 3 is greatly refined. I expect there is a lot of room for future innovation here, and development of threaded applications will continue to get easier and easier.