One of the last events at Supercomputing 2007 (SC07) was a panel titled “(Super)Computing on FPGAs, GPUs, Cell and Other Exotic Architectures” on Friday morning.

Jack Dongarra (Univ. Tennessee and ORNL) said that the HPC ecosystem is out of balance; we’ve invested heavily in hardware development, and now we need to invest more heavily in software tools and methods to use the hardware. Rob Pennington (NCSA), the panel moderator, said that the tools will appear when there are enough of these systems out there that the vendors can make money at it. I disagree with both these statements.

In response to Jack Dongarra’s statement, I agree that the investment in software tools for high performance computing has been lacking, but it’s been equally limited for hardware. While I didn’t do a comprehensive survey on the exhibit show floor at SC07 in Reno, almost all the machines displayed there were built from COTS (commodity off-the-shelf) processors, mostly x86-64 from Intel and AMD, some PowerPC from IBM, and in some cases, SPARC and MIPS. Any innovation seems to be in the interconnect, packaging, power, and cooling. Notable exceptions are traditional vector supercomputers from NEC and Cray, and the ClearSpeed accelerators. It seems the HPC market can’t support processor development; current process technology is just too expensive.

There is a great deal of hype and promise for accelerators. However, even here we depend on the commodity market to drive the technology and development, and hope to gain what benefit we can. We are in the dangerous position of depending on the scraps that fall off the PlayStation table — and if they take their picnic and go somewhere else, we’re in real trouble. If you think this is silly, try asking NVIDIA to add a feature to their graphics cards that will speed up your application but will hurt graphics performance. I can hear the laughter already.

Of more concern is what may happen with the mainstream processor business. AMD and Intel have already announced quad-core chips, with plans for eight and more. David Scott (Intel), at a focus session in the HP-CAST user group meeting the Saturday prior to SC07, noted that if you are willing to give up single-core performance, you can put a lot of cores on a single chip, with today’s technology. There are many applications where such a strategy makes a great deal of sense: web services, database transactions — anything that responds to many small, independent requests. Think Google. In fact, most computing might fall into that market, where single thread performance doesn’t matter, only the total throughput.

But not HPC. Imagine having to expose and manage five or ten times more parallelism just to deliver the same performance as a single thread today. To get actual performance improvement, you need yet another factor of parallelism.

But guess who will win that architecture argument.

As for software, the dominant programming model for parallel computers hasn’t changed in almost 20 years, except to replace PVM with MPI. (I count substituting C or C++ for Fortran as a giant step sideways.) Perhaps this is inevitable. Douglass Post (DoD, HPCMP) pointed out at the SC07 panel that the lifetime of a large code is 20 to 30 years, whereas the lifetime of any large HPC system is more like 3 to 4 years. Portability, including performance portability, is more important than peak performance on any one system.

One of PGI’s consultants told us that today’s programmers like the MPI model, if only because it makes their lives easier. They can concentrate on porting and tuning today’s algorithms and programs to MPI, which is a lot of work, but not too mentally demanding. If we move to a model where parallel programming is less work, they’ll have to take on the task of finding better parallel algorithms, which is much more challenging.

So, to correct Jack Dongarra, the problem isn’t balance. The HPC ecosystem is in perfect balance, with little investment and innovation in both hardware and software. We’re in a precarious position now.  The community is able to benefit from the COTS market, but it’s anyone’s guess how long we’ll be able to thrive there.

In response to Rob Pennington, I believe that the HPC market is too small to support an aggressive hardware business, and it’s equally true that it’s too small to support a software tools industry. It may be hard to justify the cost of a large HPC hardware installation, but at least you can proudly give tours of the machine room. It’s hard to justify a large software budget, when all you get is a CD and a book (if you’re lucky).

Take compilers as an example, something near and dear to my heart. Historically, compiler development was taken on by the processor vendor and subsidized by that business. Compilers — and operating systems — hardly generated enough revenue to pay for themselves, but they were strategic investments by the vendors. Today’s HPC compilers are supported by the workstation business, and largely driven by it.

The hope has been that workstations were as complex today as yesteryear’s supercomputers, and need the same complex compilers and tools. So there is a natural fit in requirements and solutions. But some tools are hard to build, notably compilers. If compilers were easy, we wouldn’t have library-based solutions (BLAS, Linpack, MPI, etc.), we’d have extended the languages and compilers to solve those problems. Creating, supporting, and supplying these tools is a big investment and commitment. In almost every problem space, a software vendor can make more money applying that investment and commitment to a larger market than HPC. If HPC users will also buy it, that’s great, but it’s not enough to drive the market. I’m sure that statement will produce a plethora of rebuttals from HPC software vendors, but I’d ask how much of the revenue for those products is for non-HPC platforms.

Many HPC sites act as if they believe they can (or have to) develop all their own software internally. They’ve become a community of blacksmiths, building their own tools, and proud of it, with little need or desire for third party software. To be fair, the HPC market is volatile enough that a certain amount of FUD about dependence on independent software vendors can be justified.

To correct Rob Pennington, the tools will appear only if and when they apply to a larger market, or if some company (unlikely) or government agency (perhaps likely) chooses to make a long-term strategic investment.