Original URL: https://www.theregister.com/2012/05/21/intel_v_nvidia_core_battle/

Core Wars: Inside Intel's power struggle with NVIDIA

Kepler takes Knights Corner?

By Tim Anderson

Posted in HPC, 21st May 2012 13:01 GMT

GPU Technology Conference Intel and NVIDIA are battling for the hearts and minds of developers in massively parallel computing.

Intel has been saying for years that concurrency rather than clock speed is the future of high performance computing, yet it has been slow to provide the mass of low-power, high-efficiency CPU cores needed to take full advantage of that insight.

Another angle on this is that GPUs are already designed for power-efficient massively parallel computing, and back in 2006 NVIDIA exploited its potential for general-purpose computing with its CUDA architecture, adding shared memory and other features to the GPU and providing supporting libraries and the CUDA SDK. CUDA is primarily a set of extensions to C, though there are wrappers for other languages.

jen_hsung_huang nvidia kepler gpu cuda

Huang's Tesla K20 will serve intense computing

At NVIDIA’s GPU Technology Conference in San Jose, California, last week, the company announced new editions of its Tesla GPU accelerator boards based on its “Kepler” architecture. These boards are designed for accelerating general-purpose computing rather than for driving displays. The Tesla K10, available now, has two Kepler GK104 GPUs, 3,072 cores in total, and performs at up to 4,577 gigaflops (2,288 gigaflops per GPU).

The Tesla K20, expected in the fourth quarter of 2012, uses two of the forthcoming Kepler GK110 GPU, which promises over 1,000 gigaflops double precision. “It’s intended for applications like computational fluid dynamics, finite element analysis, computational finance, physics, quantum chemistry, and so on,” explained chief executive Jen-Hsun Huang in his keynote speech.

Power efficiency, which is the true limitation on supercomputer performance, has also been a focus, and NVIDIA states a three times improvement in performance per watt, compared to the previous “Fermi” generation.

The not-yet-available K20 is really the one you want, and not only because of its better performance. Although both the GK104 and the GK110 are called Kepler, there are several key advances that only appear in the GK110. A Grid Management Unit in the GK110 enables a feature called Dynamic Parallelism, which means that the GPU can schedule its own work. Previously only the CPU could schedule work on the GPU. Dynamic Parallelism means that more code can run entirely on the GPU, for greater efficiency and simplified code.

Another GK110 advance is Hyper-Q, which provides 32 simultaneous connections between CPU and GPU, compared to just one in Fermi. The result is that multiple CPUs can launch work on the GPU simultaneously, greatly improving utilisation.

NVIDIA now projects that by 2014, 75 per cent of HPC customers will use GPUs for general purpose computing.

The rise of GPU computing must be troubling to Intel, especially as the focus on power efficiency raises interest in combining ARM CPUs with GPUs, though implementation is unlikely until we have 64-bit ARM on the market. Intel’s response is an initiative called Many Integrated Core (MIC, pronounced Mike). It has similarities with GPU computing, in that MIC boards are accelerator boards with their own memory, and developers need to understand that parts of an application will execute on the CPU, parts on MIC, and that data has to be copied between them.

Prototype Knights

Knights Ferry is the MIC prototype, available now to some Intel partners, and has 32 cores and up to 128 threads (four Hyper Threads per core). Knights Corner will be the production MIC and has more than 50 cores and over 200 threads. The processor in Knights Ferry, codenamed Aubrey Isle, is based on an older Pentium design for power efficiency, but includes over 100 additional x86 instructions including a Vector Processing Unit, important for many HPC applications. Knights Corner is expected in late 2012 or early 2013.

Intel is supporting MIC with its existing suite of tools for concurrent programming: Parallel Studio XE and Cluster Studio XE. Key components are Threading Building Blocks (TBB), a C++ template library, and Cilk Plus which extends C/C++ with keywords for task parallelism. Intel is also supporting OpenMP, a standardised set of directives for parallel programming, on MIC, though in doing so it is getting ahead of the standard since OpenMP does not yet support accelerators. Intel’s Math Kernel Library (MKL) will also be available for C and Fortran. OpenCL, a standard language for programming accelerators, will also be supported on MIC.

Xeon today, MIC tomorrow

Intel’s line is that if you have an application that takes advantage of parallel programming on the CPU today, it can easily be adapted for MIC, since the MIC processors use the familiar x86 instruction set and programming model.

“We are trying to provide the common tools and programming models for the Xeon and x86 architecture and for the MIC architecture so you can use C++, Fortran, OpenMP, TBB, Cilk Plus, MKL; not only for Xeon but for MIC as well,” said Intel technical consulting engineer Levent Akyil at the company’s Software Conference last Month in Istanbul. “You can develop for Xeon today and scale your investment to the future Intel MIC architecture.”

The advantage over CUDA is that developers do not have to learn a new language. Intel quotes Dan Stanzione, deputy director at TACC (Texas Advanced Computing Center). “Moving a code to MIC might involve sitting down and adding a couple of lines of directives [which] takes a few minutes. Moving a code to a GPU is a project,” says Stanzione.

intel_knights_ferry

Intel’s Knight’s Ferry prototype MIC accelerator board

That said, NVIDIA has partnered with CAPS, Cray and PGI to create a directive-based approach to programming GPU accelerators, called OpenACC. Compiler support is limited currently to those from the above companies, but the expectation is that OpenACC will eventually merge with OpenMP. Adding directives to their C or C++ code is easier for programmers than learning CUDA C or OpenCL.

Why use NVIDIA GPUs rather than Intel MIC? Jack Wells, director of science at the Oak Ridge National Laboratory (ORNL) in Tennessee, is doubtful that Intel’s “same code” approach will deliver optimum results. ORNL is responsible for the Jaguar supercomputer, which is the fastest in the USA and third in the world, according to the Top 500 list. The Titan project underway at ORNL involves adding 15,000 Kepler K20 GPUs to achieve over 20 petaflops performance.

“At the NSF [National Science Foundation] computing center at our facility, there is an Intel center of excellence where they have early versions of the MIC," Wells says. "The director of that supercomputing center has justified that approach based on a belief that the thousands of users associated with NSF computing center might not want to port their codes.

“But this is a delicate issue. In supercomputing, just porting codes and getting them to run is not the goal. If it doesn’t run well, it’s a bug. So our best judgment is that the same process one needs to go through to get the codes running on a GPU hybrid machine would be similar to what you would do on a MIC hybrid machine, if it’s in a hybrid mode... It is not credible to me that, even if MIC delivers good performance, that just compiling your code and running it will be satisfactory.”

Watts call the shots

Is Wells concerned that CUDA is a proprietary standard? “NVIDIA has embraced OpenACC, and that’s a development that we’re thrilled about,” he says.

Another mitigating factor against the proprietary nature of CUDA is NVIDIA’s support for the open-source LLVM compiler project. The LLVM compiler for CUDA – which in this context is the CUDA architecture and not just the CUDA language – opens up the possibility of both supporting other languages on NVIDIA GPUs, and compiling CUDA code to target other GPUs or x86 CPUs.

The key question is: Will MIC or Knights Corner offer the best performance per watt? That is an analysis that will have to wait until the production release. ®