On Tuesday, Cray announced their new XT5 product family, the next generation in their flagship XT line of supercomputers, the company’s massively parallel processor (MPP) architecture based on AMD Opteron processors. The new family encompasses two machines the XT5 and the XT5h. The XT5 proper is the follow-on to the XT4, while the XT5h represents their hybrid variant. According to Cray, the new machines are capable of scaling to sustained — not peak — petaflop performance.
Like the Sun Microsystems Constellation and IBM Blue Gene/P supercomputers, the XT5 is using quad-core technology as the lever to achieve petaflop-level performance. This follows on the heels of the dramatic increase in processing power provided by dual-core processors, when they became mainstays of supercomputers in 2005. With quad-core technology now hitting its stride, the realization of sustained petaflop machines is within reach.
“We absolutely believe that this trend is going to continue, and within the next five years you’ll see million processor systems that will be equivalent to the entire TOP500 list as it exists today,” says Jan Silverman, Cray’s senior VP of Corporate Strategy and Business Development.
The trick is how to build systems so that applications can take advantage of this level of parallelism. This is Cray’s value proposition. The company’s approach is to use a mix of standard technologies, like Opteron processors and Linux, and proprietary technologies, like their SeaStar interconnect and their home-brewed vectors processors to build elite systems. In the XT5 family, they continue this tradition.
The company first introduced its Opteron-based XT line with the launch of the XT3 in 2005. The XT4 followed in 2006. Both systems were built for longevity. Anybody with an XT3 can upgrade their hardware with XT4 and XT5 parts. According to Cray, 75 percent of the deployed XT systems have already been upgraded.
Unlike the previous XTs, the XT5 runs completely under a standard Linux environment. This opens up the architecture to off-the-shelf Linux-based ISV applications — something not possible until now. On the previous XT machines, Linux ran only on the I/O nodes. The compute nodes ran Catamount, a non-standard microkernel-based OS. The default OS that runs on the XT5 compute nodes is actually an ultra-lightweight version of SUSE Linux that doesn’t contain the I/O kernel and other system services. The idea is to unburden the OS from a lot of interrupt handling in order to achieve maximum computational performance. As it turns out though, many ISV codes assume a full Linux implementation. If the user needs to run those applications, Linux functionality is added back in, but at some cost in performance.
Silverman says customers who want to run ISV applications will be willing to take the performance hit of a fatter OS for the convenience of using off-the-shelf software. Applications that don’t need all the Linux goodies can run on nodes with the stripped down version. This is a different model than is used by traditional clusters, where a fully configured Linux runs on each node.
An XT5 cabinet contains 768 Opteron cores and delivers about 7 peak teraflops, while consuming something in the neighborhood of 42 KW. A 43 teraflop system could fit into just six cabinets. To achieve this same level of performance, an XT3 system takes 120 cabinets. But it’s not just about peak teraflops. The system is designed for scalability so that you don’t get diminishing returns as you add more compute muscle.
Maybe the architecture’s most important technology for enabling scalability is its 6-port SeaStar router, the basis of Cray’s 3D Torus high performance interconnect. The version in XT5 is SeaStar2+, which the company says has 30 percent greater performance than the SeaStar2 router on the XT4 blade. But since the SeaStar2+ connects to two Opteron chips, versus one for the SeaStar2, the XT4 blade actually offers a better communication/compute ratio than the newer XT5.
Fortunately, XT4 blades can be installed in XT5 cabinets in any combination with XT5 blades. In a lot of cases, the XT4 blades still make sense, since the one-to-one SeaStar-Opteron connection is better for applications where communication bandwidth is paramount. The XT5 blade would be the better choice for CPU-intensive workloads or where the applications can benefit from the additional memory within the node (32 GB for the XT5, versus 8 KB for the XT4).
Since the new machine runs Linux, Cray is planning to attract commercial users that want to run ISV applications at a scale beyond what a typical cluster solution could provide. Automobile crash-test simulations that model the complex interaction between cars and humans is one such example. This represents part of Cray’s strategy to move beyond the research centers and government labs. With the high reliability they believe they’ve achieved in the second and third generation XT4 and XT5, Cray is now positioning these machines for operational work. One example is the 5 teraflop XT4 system used by MeteoSwiss for its around-the-clock weather forecasting.
The other half of the XT5 family, the XT5h, is the architecture that includes vector processor blades and FPGA blades. The XT5h replaces Cray’s FPGA-equipped XD1 product and X1E vector machines. The new machine offers the ability to utilize multiple compute architectures, as well as support global memory programming. It represents a significant step toward Cray’s goal of offering adaptive computing systems. Adaptive computing is a model intended to optimize both programmer productivity and computing resources by enabling software components to run on the most suitable hardware available in the system. This XT5h platform represents Cray’s first integrated hybrid computing architecture for heterogeneous computing.
The FPGA blade, called XR1, is made up of two pairs of Opteron processors hooked up, via HyperTransport, to two DRC-supplied Reconfigurable Processor Units (RPU). According to Cray, this tight processor coupling ensures low latency and high-bandwidth communication between the processing elements, allowing users to scale applications to thousands of FPGAs.
The vector blade, called the X2, has four high-bandwidth, 25 gigaflop vector CPUs, along with 64 GB of shared memory, implemented as a four-way SMP. Each X2 node delivers more than 100 gigaflops (peak), and the system can be scaled to 1,024 shared memory processors with 16 terabytes of globally addressable memory. These blades go into dedicated vector processing cabinets, which are connected via the SeaStar network to at least one XT5 cabinet, which itself may be minimally configured.
Because of the global memory architecture of the X2, partitioned global address space (PGAS) languages like Co-Array Fortran (CAF) and Unified Parallel C (UPC) may be used. These languages allow developers to take advantage of the shared memory architecture of the X2. In some cases, you can achieve an order of magnitude improvements in both programmer productivity and runtime performance when compared to the MPI model. Silverman believes customers will buy the vector blades just to use the global memory architecture, whether or not they want to use the vector processors themselves.
The UK’s High End Computing Terascale Resource (HECToR) is Cray’s first hybrid deployment. The current machine consists of XT4 cabinets. They’ll be adding an XT5h vector computing cabinet, which will hooked up to the current system as soon the X2 hardware becomes available in 2008.
An application well-suited to hybrid architectures is climate simulation. The model consists of three main components: the atmosphere, the ocean, and the land. It turns out the atmosphere portion of the model is very well suited to scalar CPUs, like Opterons. But the ocean portion of the model can be easily vectorized and also benefits greatly from the high bandwidth memory access. The land model is also suited to scalar CPUs, but some sections of the code can be accelerated by offloading it to FPGAs.
“So the idea is that you would optimize this whole job by putting the right set of application pieces on the processor that can best execute the code, rather than try to fit everything into one architecture,” explains Silverman. “That, in a nutshell, is the benefit of a hybrid machine.”