In this week's issue, PGI's Michael Wolfe writes a thoughtful piece about our changing attitudes towards high-end computing productivity and how it relates to compilers and software in general. Wolfe highlights some of the difficulties of defining productivity and the limitations of those attempts. Reading the article got me to thinking about a topic that is often missing from the discussion: how computing productivity fits into our overall goals of increasing value. The assumption is that increased productivity will automatically give us better computing systems via some trickle-down effect. But we may be disappointed.

Wolfe himself alludes to this when he questions the utility of increasing productivity at the expense of performance. "We may measure productivity as performance/cost, but we don't get true high productivity by simply reducing the denominator faster than we reduce the numerator," he says. In essence he's implying that productivity, at least in the narrow definition of the term, is not the end game.

Let's say we find a great new programming language that makes it easy to churn out a low-performing atmospheric modeling application. What's the point? The cost saved in producing the software will be lost if slower execution prevents it from predicting weather events in a timely manner. In addition, the new language may not have the tool support or portability of a less productive language, which threatens the longevity of applications developed with it. It seems fairly obvious that increasing productivity for its own sake won't necessarily lead to practical outcomes. (The same sort of disconnect occurs when economists talk about maximizing the efficiencies of the market, ignoring the fact that the point of economies is to maximize the financial well-being of actual people.)

So what is the end game for high-end computing, or any computing, for that matter? Let's simply call it "usefulness" -- the attribute of how much value can be derived from a computing system over its lifetime. Now I suppose we could try to merge usefulness into the definition of productivity, but that seems like a bit of a semantic stretch. Usefulness has to do with how practical something is, not just how efficiently it operates. In business-speak they talk about return on investment (ROI), which is the ratio of money lost or gained in relation the the money invested. This might be a decent starting point for measuring usefulness. But I suspect a larger perspective is required.

On its best days, the government actively looks for ways to seek out useful solutions for the people it represents. That's why the feds are funding DARPA's High Productivity Computing Systems (HPCS) program. The goal of this effort is to produce a new generation of economically viable HPC systems for government and industry by 2010. Even though productivity is HPCS's middle name (literally), I'm hoping that the people involved in the program will not lose sight of the goal of creating practical systems.

While commercial organizations tend to act in their own self interest, they usually have a bigger role to play than the government in producing useful computing systems. Since customers generally demand practical solutions, vendors are focused on accommodating them. In today's environment, users require that computing systems be more than just technically sound and inexpensive. They want to be assured that what they buy is well-supported, and if possible, not dependent upon the control of a single vendor. This encourages companies to form consortiums, establish standards, and contribute intellectual property to the community.

A recent example of the latter is Intel's release of their Threading Building Blocks (TBB) library into the open source community, which I write about in this week's issue. The TBB library can be used to develop C++ applications for multicore environments using high-level task parallelism. By avoiding having to program and debug low-level thread and lock management, developers should realize increased productivity. And according to Intel, the performance of TBB is as good or better than most hand-coded versions of parallel programming.

But even though the TBB software offered both performance and productivity, users wanted more. They told Intel they would like the software to run everywhere, not just on x86 processors, and not necessarily just on Linux, Windows and Mac OS. Users expressed that they would also rather not be dependent upon Intel to maintain this library over the lifetime of their applications. They weren't worried that Intel would disappear, just that the company might decide to pull the plug on the software at an inopportune time. From a business standpoint, Intel is very interested in getting the TBB software into the multicore ecosystem, but would rather not be bothered with implementing each OS and processor port.

Open source was the logical answer to make this software truly useful. Although TBB is currently only suited for low-end HPC today (it scales up to a few dozen cores), now that the software is available to the open source community, it is more likely to attract the attention of developers with bigger things in mind.

I suppose it seems a little premature to be talking about high usefulness computing as a successor to high productivity computing. We don't yet have a good grasp on how to measure and improve productivity. I'm certainly not advocating we stop looking at how to make our software processes and hardware systems more efficient. And I'm not changing the publication to HUCwire anytime soon. But I think it is worthwhile to keep in mind that increasing productivity is just a means to an end, not an end unto itself.

-----

As always, comments about HPCwire are welcomed and encouraged. Write to me, Michael Feldman, at editor@hpcwire.com.