The Portland Group – HPCwirehttps://www.hpcwire.com
Since 1987 - Covering the Fastest Computers in the World and the People Who Run ThemTue, 20 Mar 2018 00:17:45 +0000en-UShourly1https://wordpress.org/?v=4.9.460365857NVIDIA Eyes Post-CUDA Era of GPU Computinghttps://www.hpcwire.com/2011/12/07/nvidia_eyes_post-cuda_era_of_gpu_computing/?utm_source=rss&utm_medium=rss&utm_campaign=nvidia_eyes_post-cuda_era_of_gpu_computing
https://www.hpcwire.com/2011/12/07/nvidia_eyes_post-cuda_era_of_gpu_computing/#respondWed, 07 Dec 2011 08:00:00 +0000http://www.hpcwire.com/?p=4600Lost in the flotilla of vendor news at the Supercomputing Conference (SC11) in Seattle last month was the announcement of a new directives-based parallel programming standard for accelerators. Called OpenACC, the open standard is intended to bring GPU computing into the realm of the average programmer, while making the resulting code portable across other accelerators and even multicore CPUs.

For obvious reasons, OpenACC is being heavily promoted and supported by NVIDIA, but it is The Portland Group (PGI) and Cray who are driving the early effort to commercialize the technology. PGI already has implemented a very similar a set of accelerator directives, which became part of the foundation for the OpenACC standard. Cray is developing its own OpenACC compiler and its XK6 customers, like Oak Ridge National Lab and the Swiss National Supercomputing Centre, are expected to be among the first supercomputer users of the technology

In a nutshell, OpenACC directives work much the same as OpenMP directives, but are specifically applicable to highly data parallel codes. They can be inserted into standard C, C++ and Fortran programs to direct the compiler to parallelize certain code sections. The compiler takes care of the logistics of moving data back and forth between the CPU and the GPU (or whatever) and mapping the computation onto the appropriate processor.

The idea is to enable developers to make relatively small modifications to existing (or new) code in order to expose parallel regions for acceleration. Since the directives are designed to apply to a generic parallel processor, the same code can run on a multicore CPU, GPU, or any other type of parallel hardware that is supported by the compiler. This hardware independence is especially important to the HPC community, which is loathe to adopt vendor-specific, non-portable programming environments.

From NVIDIA’s perspective, the overriding goal is to bring GPU computing into the post-CUDA age. CUDA C and Fortran are the most widely used programming languages for GPU programming today, but the underlying technology is proprietary to NVIDIA and offers a relatively low-level software model of GPU computing. As a result, the use of CUDA today tends to be restricted to computer science types, rather than the average programmer or researcher.

OpenCL, which is supported by NVIDIA, AMD and many others, also provides a parallel programming framework for GPUs and other accelerators, and unlike CUDA, is a bona fide open standard (under the direction of the Khronos Group — the same organization that brought us OpenGL). But like CUDA, OpenCL is relatively low-level, requiring a fairly intimate knowledge of the inner workings of the target processor. Therefore, like CUDA, use of OpenCL is mostly confined to computer scientists.

NVIDIA estimates there are over 100,000 CUDA programmers on the planet and a substantially smaller number of OpenCL developers, but they see a much larger potential audience if they can make GPU programming more open and developer-friendly. Essentially they believe OpenACC will be able to make GPU technology accessible to the millions of scientists and researchers who don’t care to dabble in the low-level intricacies of processor architectures and chip-to-chip communications.

Steve Scott, CTO of NVIDIA’s Tesla business unit, sums up the goal of OpenACC thusly: “What we’d like to do at this point is to substantially increase the breadth of applicability and the number of people using GPUs.”

According to Scott, the high-level nature of OpenACC is not going to impact execution performance significantly. While in his previous CTO role at Cray, he encountered accelerator directives-based codes that were getting within 5 or 10 percent of the performance of hand-coded CUDA. According to him, that was fairly typical. Some applications, Scott says, were even doing better than their CUDA alternates, thanks to the ability of the compiler to optimize certain codes beyond what mere mortals could achieve. In any case, OpenACC is designed to be interoperable with CUDA, so hand-tuned kernels can work seamlessly with directives-based code if need be.

Besides PGI and Cray, CAPS enterprise, a French developer of multicore software tools, has also signed up to support the new directives. All three vendors are expected to have compilers with OpenACC support ready in the first half of 2012. Notably missing from the list of OpenACC supporters are Intel and AMD, although both have processors (multicore x86, AMD APUs and GPUs, and the Intel MIC) that would certainly be capable targets. That wouldn’t necessarily stop PGI, CAPS, or Cray from building OpenACC-enabled compilers for Intel and AMD hardware, however.

PGI and NVIDIA are in the process of running a free 30-day trial for developers interested in kicking the tires on PGI’s current accelerator directive compiler. The claim is that the technology will at least double application performance with less than 4 weeks of developer effort. Hundreds of researchers have already registered for the trial and this week NVIDIA has reported some initial results. At least one developer was able to get a 5X performance boost on his application after just a single day of tweaking the code.

But the real end game for OpenACC supporters is for the directives to be incorporated into the OpenMP standard. Since OpenACC was derived from work done within the OpenMP Working Group on Accelerators, it stands to reason that this will indeed happen. Although there is no timeline for when the technology will be folded into OpenMP, it’s most likely to be occur in conjunction with the release of OpenMP 4.0, which is expected to be launched sometime in 2012.

]]>https://www.hpcwire.com/2011/12/07/nvidia_eyes_post-cuda_era_of_gpu_computing/feed/04600The Not-So-Unlikely Marriage of CUDA and x86https://www.hpcwire.com/2010/11/16/the_not-so-unlikely_marriage_of_cuda_and_x86/?utm_source=rss&utm_medium=rss&utm_campaign=the_not-so-unlikely_marriage_of_cuda_and_x86
https://www.hpcwire.com/2010/11/16/the_not-so-unlikely_marriage_of_cuda_and_x86/#respondTue, 16 Nov 2010 08:00:00 +0000http://www.hpcwire.com/?p=5041NVIDIA's CUDA is easily the most popular programming language for general-purpose GPU computing. But one of the more interesting developments in the CUDA-verse doesn't really involve GPUs at all. In September, HPC compiler vendor PGI (The Portland Group Inc.) announced its intent to build a CUDA compiler for x86 platforms. The technology will be demonstrated for the first time in public at SC10 this week in New Orleans.

]]>NVIDIA’s CUDA is easily the most popular programming language for general-purpose GPU computing. But one of the more interesting developments in the CUDA-verse doesn’t really involve GPUs at all. In September, HPC compiler vendor PGI (The Portland Group Inc.) announced its intent to build a CUDA compiler for x86 platforms. The technology will be demonstrated for the first time in public at SC10 this week in New Orleans.

To delve a little deeper into the what’s behind the CUDA x86 effort, HPCwire asked PGI senior compiler engineer Michael Wolfe about the rationale for producing such a product and how the technology will work.

HPCwire: Why CUDA for x86? Aren’t there enough parallel programming environments already available for this architecture?

Michael Wolfe: There are certainly many parallel programming approaches today, and no one would have created an analog to CUDA if the x86 were the only target. However, CUDA has been quite successful for programming NVIDIA GPUs. There are now customers who want portability of their CUDA programs beyond NVIDIA and GPUs. The PGI CUDA X86 compilers will provide that portability.

HPCwire: Do you think there is existing demand for such a product, or is this more of a if-we-build-it-they-will-come approach?

Wolfe: There is definitely demand for this. We approached our customers and surveyed the market before proceeding. We didn’t come up with this idea on our own.

HPCwire: What x86 hardware is being used to map the CUDA functionality? Is the intent to support both Intel and AMD platforms going forward?

Wolfe: We think of today’s GPUs as exploiting three levels of parallelism: SIMD parallelism within a “warp” (or thread block) and within a streaming multiprocessor; MIMD parallelism across thread blocks and across multiple streaming multiprocessors; and multithread parallelism, used to tolerate device memory latency. Today’s x86 processors have SIMD parallelism in the SSE (and soon AVX) instructions and MIMD parallelism across the multiple cores. Intel processors even support a limited amount of multithread parallelism. Our compilers will use the SSE, AVX and multicore parallelism.

HPCwire: What’s the point behind compiling to a “Unified Binary?” Using the same code base to target different platforms seems obvious, but at run time, won’t users know what the target is? Are you envisioning a cluster deployment scenario where only some of the nodes are equipped with GPUs, with the rest CPU only?

Wolfe: It’s not likely users will make production runs on clusters where only some of the nodes are GPU-enabled. The PGI Unified Binary allows HPC users who regularly access multiple server platforms to build one version of their application that is optimized for Intel, AMD and GPU-enabled compute nodes. Some sites even use it to ease the transition from one generation of Intel or AMD CPU to the next. The PGI Unified Binary for multiple x86 CPUs has been quite popular with independent software vendors who want to ship optimized applications without having to manage a different binary for each different processor type. We expect the same to be true for CUDA; a vendor or developer can produce a single executable that will execute using a GPU when available, and use the host otherwise.

HPCwire: Beyond that, is their any utility to writing x86-specific CUDA source code that is optimized for the CPU?

Wolfe: As I said before, an API-based programming model like CUDA probably would never have emerged simply to support multicore x86 CPUs. It was designed with the structure required for efficient GPU programming and for programming heterogeneous systems with multiple memories. That said, it can be compiled for efficient execution on x86 using multiple cores and SSE/AVX to effect parallel execution. For that reason, it has value as a uniform parallel programming model across GPUs and multicore x86.

HPCwire: Is there any intelligence in the compiler to map some of the CUDA parallelism to the CPU and some to the GPU, based on available resources?

Wolfe: CUDA is a relatively low-level programming model. The program — meaning the programmer — explicitly allocates memory on the GPU or CPU device, copies data to and from the memory, and launches kernels on the device. It’s beyond the scope of a CUDA compiler to distribute the data across multiple memory spaces, manage the data motion between them, and decide what parts of the kernel domain to allocate to what devices.

HPCwire: You are demonstrating the technology at SC10. What’s the timeframe for the product launch?

Wolfe: The product will launch in three phases. The first phase, due in Q2 2011, will include CUDA functionality on the x86, allowing execution and debugging, but not optimized for high performance. The second phase, planned for Q4 2011, will use the SSE and/or AVX instructions and other performance optimizations. The third phase will include the Unified Binary technology, allowing a single executable to run on the GPU or the x86. The time frame for phase three is sometime in mid-2012.

HPCwire: What will it cost?

Wolfe: The current plan is to add CUDA C for multicore x86 as a new feature in our existing PGI Accelerator product line. Customers who already have PGI Accelerator licenses with active subscriptions will get PGI CUDA C at no extra cost as part of their standard release updates when it rolls out.