Last week’s International Supercomputing Conference (ISC’09) was a convenient excuse for vendors to announce a raft of new products, but three, in particular, stood out. Storage vendor DataDirect Networks (DDN) launched its new “Storage Fusion Architecture” that gives it an IOPS story; Mellanox jumped into the InfiniBand switch and fabric management business in a big way; and PGI released its first C and Fortran compilers with support for GPU acceleration.

DataDirect Does IOPS

DataDirect Network’s historical leadership in high throughput storage has kept it atop the supercomputing world. Today, eight of the top 10 systems use DDN gear, including the petaflop-capable Jaguar supercomputer at Oak Ridge National Lab. Storage demand continues to grow in HPC, but it’s growing even faster in other areas like Web services and media content.

With that in mind, DDN is looking to tap into a bigger slice of that market with a revamped architecture. In truth, DataDirect has already begun this transition. According to DDN senior director of product management Josh Goldenhar, the revenue breakdown for the company is now 45 percent HPC, 30 percent rich media, and most of the remainder Web 2.0 type applications.

With its next-generation storage platform, called Storage Fusion Architecture (SFA), the company is looking to add a high performance random access capability on top of high performance throughput, the idea being that I/O per second (IOPS) is the critical metric for all this unstructured data that is spreading across the storage landscape. Even in HPC, high IOPS is becoming a necessity. Multicore computing means structured data access is becoming randomized, since I/O now tends to be performed across multiple threads. In particular, metadata is becoming the choke point for large clustered file systems since it tends to be accessed randomly.

The SFA design is based on a controller couplet pair that can support up to 1,200 disk drives, which can be a mix of SATA, SAS, and SSD devices. That mean that with the new 2 TB SATA drives, a single controller pair can drive 2.4 petabytes of storage.

Data throughput for a single controller is 10 GB/second — significantly better than the 6 GB/second provided by the current generation S2A design. But the real story is the IOPS. An SFA controller can deliver up to 1 million IOPS to cache storage and 300 thousand IOPS to disk. The high disk IOPS will be especially important to users who want to get the most out of attached SSD devices, which support much faster read/write speeds than their spinning brethren.

The SFA controller hardware itself is very different from the current generation S2A technology. DDN has made the jump to a CPU-based architecture (in this case Intel Nehalem), dumping the FPGAs it relied on in previous generations. By doing this, the company is able to take advantage of standard x86 technology, PCIe Gen2, and DDR3 memory. Part of the memory (16 GB) is used for storage cache, which is why DDN was able to achieve such high rates of cache IOPS. Perhaps more importantly, the standard platform will allow DDN to create new features much more easily than on an FPGA-based platform. “We are poised to take advantage of the very same advances in CPU technology that have been aiding our clients, in the storage itself, with a completely multithreaded storage engine under the covers,” said Goldenhar.

Early SFA products are in customer trials in California and Europe, with general availability scheduled for September.

Mellanox Adds Big InfiniBand Switches, Fabric Management Software

Also at ISC, Mellanox Technologies launched its first director-class InfiniBand switches and fabric management suite. The IS5000 modular switches support from 108 to 648 QDR ports and are paired with the company’s new FabricIT management software to support large scaled-out clusters comprised of thousand or tens of thousands of nodes. The IS5000 is a true modular architecture: the platform makes use of common leaf and spine components, as well as interchangeable power supplies and fans. Mellanox has also added a new 36-port fixed switch, which is able to support the fabric management software. The older 36-port MTS3600 switch was externally managed since it lacked a CPU.

With Mellanox’s expanded portfolio, the InfiniBand switch and fabric management space is starting to look ever more crowded. The other InfiniBand players — Voltaire, QLogic and Sun Microsystems — have all recently introduced QDR director-class switches of their own. QLogic has the largest general-purpose switch to date, with up to 864 ports; the other three vendors top out at 648 ports (not including the 3,456-port Magnum switch Sun reserves for Constellation supers).

As Mellanox has moved up the food chain, the situation has become a bit tricky. With the addition of a fully-populated switch portfolio, the company’s current partners — Sun and Voltaire — are ostensibly competitors. Mellanox provides its own InfiniBand chips to Sun and Voltaire, as well as using them natively. (QLogic also produces InfiniBand silicon, but keeps the technology in-house for its own products.) Although InfiniBand use is expanding, it’s not clear if there will be enough market space to support multiple vendors with similar offerings. According to John Monson, VP of marketing at Mellanox, vendors are carving out their own niches in the InfiniBand market with regard to vertical segments and server OEM relationships, and have different value propositions. “There’s plenty of room in the market for that competition, but there will be some overlap,” he admits.

With the addition of the director-class switches and the fabric management software to its traditional portfolio of host channel adapters, device silicon, gateways, and Ethernet product offerings, Mellanox has filled in its product set rather completely. The addition of the fabric management suite was a big step for the company. As InfiniBand use expands to less traditional HPC users and with increasing cluster sizes, ease of management will be much more important. And to the extent InfiniBand can make inroads into the enterprise and cloud computing realm, a fabric management capability becomes a must-have feature.

PGI Adds GPU Computing Support to Compilers

A year and a half ago, compiler vendor PGI (aka The Portland Group) came to the conclusion that heterogenous computing, via accelerators, would probably be the next big thing in technical computing, and began a strategy to support that model in its software tools. PGI Release 9.0 brings the first implementation of that work to fruition, with the support of NVIDIA GPUs for general-purpose computing via the company’s C and Fortran compilers.

Unless you’re brand new to HPC, you know that GPU computing has become the accelerator of choice on a range of HPC platforms — from personal workstations and small clusters to large supercomputers. Accelerating HPC applications with the latest GPUs can result in performance increases of one or two orders of magnitude compared to CPU-only execution. NVIDIA has largely been driving this new model, using its own CUDA development environment as the software platform.

Although CUDA source code is written in C, functionally it represents a rather low-level interface to GPU computing. PGI’s idea is to hide the GPU device management details of CUDA, and let the compiler generate GPU code directly from the C or Fortran application source. In practice though, this is not completely transparent to the developer. The model used by PGI is based on directives that the programmer must insert into the source code at the appropriate spots — similar to what’s done with OpenMP directives. The goal is to locate all the computationally-intensive portions of the code that can be parallelized on GPU hardware and direct the compiler to generate the low-level code. The most common directive is called ACC REGION. For example:

SUBROUTINE SAXPY (A,X,Y,N)
    INTEGER N
    REAL A,X(N),Y(N)
!$ACC REGION
    DO I = 1, N
       X(I) = A*X(I) + Y(I)
    ENDDO
 !$ACC END REGION
 END

The loop inside the ACC REGION will be parallelized by the compiler and the GPU code will be bundled into the executable file alongside the regular CPU code. At runtime the parallelized code will be downloaded to the GPU and executed natively, with all the data transfers to and from the device managed automatically. Under the covers, the compiler is employing CUDA as the low-level interface to do the device-specific work. Note that if a GPU is not detected, the runtime falls back to the CPU version of the code.

The directives are not the whole story. To squeeze maximum performance from the GPU, there is usually some source tweaking required in order to optimize the runtime behavior. The GPU memory system in particular is vastly different from the typical CPU, and the programmer must recognize that matching data to the on-board memory is going to boost performance. “The compiler is not magic,” explained Doug Miles, director of The Portland Group. “It can’t automatically detect, offload and optimize appropriate kernels. It can do a lot of the busywork. But the programmer is going to have to be in the loop.”

The first PGI implementation is Linux only and assumes an x86 CPU host with a CUDA-capable NVIDIA GPU. There are a few other limitations, mostly associated with the fact that CUDA is not really multi-GPU aware, so execution is currently limited to one GPU per application. PGI is also “investigating” a GPU implementation for AMD’s FireStream computing platform, but will need a working OpenCL implementation for that target.

The accelerator capability in the compilers is available at no charge until the end of 2009 for users with a working PGI Linux license. Starting in 2010, the acceleration features will require a license upgrade, with pricing to be determined. For more information, check out the FAQ on PGI’s Web site at http://www.pgroup.com/resources/accel.htm.