Compilers and More: OpenACC to OpenMP (and back again)

By Michael Wolfe

June 29, 2016

In the last year or so, I’ve had several academic researchers ask me whether I thought it was a good idea for them to develop a tool to automatically convert OpenACC programs to OpenMP 4 and vice versa. In each case, the motivation was that some systems had OpenMP 4 compilers (x86 plus Intel Xeon Phi Knights Corner) and others had OpenACC (x86 plus NVIDIA GPU or AMD GPU), and someone wanting to run a program across both would need two slightly different programs. In each case, the proposed research sounded like a more-or-less mechanical translation process, something more like a sophisticated awk script, and that’s doomed from the start. I will explain below in more detail how I came to this conclusion. However, there is a germ of a good idea here, so I will follow with a summary of a research idea that someone could start with.

Why Simple Conversion is Insufficient

OpenMP was first released in 1997 (initially for Fortran). It started as a group of multiprocessor vendors (including SGI, IBM, Sun, HP) who essentially agreed to spell parallel do the same way. Each vendor already had its own set of parallel directives, but agreeing on a spelling and meaning would allow programs to be ported across systems. OpenMP was actually the second attempt to get vendors to agree on such a spelling; the Parallel Computing Forum predated OpenMP by some years, and many of the ideas proposed by the PCF were later used in the development of OpenMP. OpenMP has been very successful and is widely adopted in the scientific and technical computing community.

Agreement on both the spelling and meaning for OpenMP was important. Agreement on the meaning became agreement on the implementation, and to improve efficiency on the systems of the day, the OpenMP committee chose a careful, prescriptive definition of the parallel constructs. OpenMP is thread-centric, and describes how many threads are created and how the parallel work is distributed across those threads. This approach was appropriate as a solution for the machines of the day, where a multiprocessor had only single- digit parallelism, vector machines were waning, and thread startup costs were prohibitively high. However, these constraints no longer apply.

OpenACCOpenACC was released in 2011, specifically to support parallel computing on accelerators, including GPUs, as well as other parallel systems. I was involved in the earliest meetings, and from the very start we worked to design a solution that would be effective for a wide variety of target systems: host+GPU; host+Clearspeed accelerator; host+Cell processor; host+Digital Signal Processor; host+Intel MIC (then, the prototype Knights Ferry, now the Xeon Phi); AMD Fusion APUs with a CPU and GPU on a single die, as well as multicore CPUs. To support such a wide range of targets, OpenACC took a more descriptive approach, to use the directives to describe properties of the program, allowing the compiler and runtime to choose runtime values appropriate for the target system. For instance, where a multicore system may only have 4 or 8 or 16 cores, implying that only so many parallel threads are sufficient, a highly parallel GPU may require hundreds or thousands of threads to efficiently utilize the hardware. Encoding those values into a parallel program seemed like a recipe for program obsolescence.

In 2013, OpenMP 4.0 was issued with support for accelerators and with much similarity to OpenACC. Both OpenMP 4 and OpenACC have data directives and clauses, and parallelism directives. The data directives are used when compiling for a host+accelerator system where the accelerator has a separate physical and/or virtual memory, and control data movement between system and device memory. The data directives and clauses in the two specifications are mostly coherent, meaning it is mostly feasible to mechanically convert OpenACC data directives to OpenMP 4, and vice versa.

OpenMPIt’s a very different story for the compute directives. OpenMP was designed in a world with only a few SMP processors on each system, so it was reasonable to include a wide variety of synchronization primitives. OpenMP includes atomic operations, critical sections and ordered critical sections, single and master sections, barriers, doacross dependences between loop iterations, parallel sections, tasks and task dependences, and explicit management of locks. Most of these are nonscalable, either limiting the amount of parallelism that can be expressed, or will run afoul of Amdahl’s Law limiting the amount of benefit you get when running in parallel. Of these, OpenACC includes only the atomic operations. This restricts the kind of program you can write using OpenACC, but it also means the programs you write will be more scalable to future systems. That means converting an OpenMP program containing these constructs to OpenACC is a nonstarter.

But it goes much deeper than that. Even for the simple cases where OpenMP and OpenACC intersect rather closely the two specifications have different definitions and implementations. As described in more detail in an earlier article about parallel loops, OpenMP is defined in terms of threads and how the work is shared across threads. If the program specifies using 32 threads, then that’s how many you’re going to get. Someone will point out that the implementation can in fact reduce that number, but there’s no provision for increasing it. If you have a target with more parallelism available (think Intel Xeon Phi x200 Knights Landing with up to 72 cores and 4 hardware threads per core), the compiler or runtime can’t just bump that up to 288 threads. It can’t even use the parallel directive to help the compiler silently auto-parallelize within an OpenMP thread; the directives state that the program can’t have any data races across threads, but it says nothing about data races across loop iterations scheduled to the same OpenMP thread. This is the key reason that OpenMP needed the simd directive and clause; even saying omp parallel for doesn’t tell the compiler that it’s safe to vectorize the loop, so a new directive was added.

OpenACC, on the other hand, does require that a parallel loop be data-race free across loop iterations. This gives the compiler a significant amount of freedom. Just saying acc parallel loop allows the compiler to generate multicore code, as well as vector or SIMD code for targets which support that. This is both simple and powerful, and enables the user to write a single version of their his or her program that can be compiled for several different targets.

Many programmers are unwilling to give that control to the compiler, and it’s certainly true that smart programmers are always going to be smarter than any compiler. However, compilers are tireless. Programmers are not, and architectures change faster than programs. We need a programming model that encourages scalable parallel programming, and that allows that parallelism to be remapped across a wide range of hardware parallelism, such as what we see on the immediate horizon and beyond.

But this isn’t a diatribe about the advantages of OpenACC or OpenMP over the other, it’s about converting from one to the other. If I want a tool to translate an OpenMP parallel loop to an OpenACC parallel loop, the conversion is no longer mechanical. The tool must determine whether the loop is truly a data-race-free parallel loop, and if not, either run it sequentially, or somehow (magically) convert it into a loop that is. Either way, such a tool requires much deeper analysis and more work than the researcher probably wants to undertake.

Going the other way, converting OpenACC to OpenMP, sounds easier. Once you know it’s a parallel loop, it’s certainly safe to write that loop using OpenMP. However, there are two parts to the parallelism in an OpenACC loop: identifying the parallelism, and mapping the parallelism onto the hardware. OpenMP 4 and OpenACC each have three levels of parallelism. OpenMP has teams of threads which can execute simd operations, where OpenACC has gangs of workers which can execute vector operations. Many OpenACC programs use the directives to identify the parallel loops, and leave much of the mapping to the compiler. As mentioned above, a loop prefixed with acc parallel loop, with no other clauses, will run in parallel, and depending on the target, it may run across gangs, or both gangs and vector lanes, with the decision made by the compiler. With nested loops, the number of possible mappings increases. An OpenMP program, however, uses a different directive for parallelism across teams (distribute) from parallelism across threads (for or do) and from SIMD parallelism (simd). So, an OpenACC program with three loops:

 

would have to be more explicit in OpenMP:

Moreover, when targeting a simple multicore CPU, you may want a completely different program. Multicore compilers currently ignore the teams and distribute directives, if they parse them at all yet, so that level of parallelism is lost. It may be better to write this program differently, collapsing the two parallel loops:

In any case, the conversion in either direction is no longer mechanical, and hence, in my opinion, any attempt to do a simple bidirectional translation is a waste of effort.

The Research Proposal

However, when reconsidering these proposals, I decided that there is a kernel of a good idea here. The goal is to be able to write a single program that runs across as wide a variety of systems as possible, and the availability of coherent OpenMP and OpenACC implementations are a problem. I think someone could do a one-way translator, from OpenACC to OpenMP, and learn enough from that process to deliver novel research results, and produce a useful translator as well. For those systems that have OpenMP but don’t (yet) have OpenACC, such a translator can be immediately useful. As hinted at in the last section, the research component is to create a target-specific parallelism mapping scheme, so that the parallelism in the program gets exploited appropriately for that target. There could be a learning process, or a user-specification of the mapping, or predicates based on program characteristics such as data access patterns.

So, what follows is a prototype of a research proposal for creating such a translator. Feel free to copy and edit these ideas to create your own proposal. If you want, you can send me your own proposal; I’ll keep it confidential, make suggestions, and if it looks good, I’ll even be glad to write an endorsement. If you are a program manager at a funding agency and receive such a proposal, I’ll be glad to review it and will be as direct and (brutally) honest as I always am.

Cover Page

Parallel Programming Model Translator

The University of Intelligent Beings

Earth, Sol System

Project Summary

This project will create a tool that converts Fortran, C and C++ programs containing OpenACC [1] directives into target-specific OpenMP [2] directives. The main artifact of the project will be a source-to-source program conversion tool, named MPACCT (pronounced “impact”) that will be distributed and available for use by HPC programmers when targeting their programs for different architectures.

The major research goal of the project is to explore, evaluate and prioritize the various ways that the parallelism in a program, expressed in OpenACC, should be targeted for different parallel systems. To augment the parallelism expressed in OpenACC directives, we will implement various classical compiler loop autoparallelization strategies, as is common in commercial OpenACC compilers. The generated output program, expressed in OpenMP, will include specific mappings to teams, threads and simd operations. The generated output will depend on: (a) characteristics of the input program, such as data reference patterns and loop structures; (b) features of the target system, such as whether it is a multicore or host+accelerator and the parallelism profile of the multicore and/or accelerator; (c) features of the target compiler, such as the program structures for which it is optimized and basic capabilities.

An ancillary research goal is to develop a characterization and representation of the parallelism profile of a target system that we can use in MPACCT. This will include such obvious items as the number of cores, hardware threads and preferred vector or SIMD length. We expect to include other features, such as information about the cache hierarchy and any hardware synchronization features. An artifact from the project will be a published representation of the parallelism profile for the variety of parallel systems that we use in our experiments. The parallelism profile for the target system will be an additional input to MPACCT.

Another ancillary research goal is to study whether we can develop a language that would allow an expert developer to control the parallelism mapping process in MPACCT. To be successful, the MPACCT mapping feature must be entirely exposed, with no hidden decisions. The language will allow the developer to control the mapping based on characteristics of the program and the target machine. We plan on an extensible language to allow for future systems that need additional program characteristics which we can’t yet envision.

Finally, a fourth goal is to develop parallel programming, architecture and compiler expertise in our students, and to use this to improve parallel systems education.

Project Description

Future high-end computing systems are being designed with much higher node parallelism than we have available today. We see systems like Cori at NERSC being installed with a Intel Xeon Phi Knights Landing processor in each node, with support for four hardware threads per core and 512-bit SIMD instructions. We have designs in place for the CORAL Summit and Sierra supercomputers at ORNL and LLNL, with multiple IBM OpenPOWER CPUs and multiple NVIDIA Volta GPUs in each node. In these future systems, exploiting parallelism on a node will be critical to getting the best performance.

In HPC, inter-node parallel programming is dominated by MPI, and that’s not likely to change in the near future. This project does not attempt to replace or augment MPI across nodes. Many current HPC programs use MPI within a node as well. This will become less suitable in the future. As the on-node parallelism increases, the number of MPI ranks would increase, reducing the memory available per rank and increasing the amount of data being uselessly copied between ranks on the same node. Moreover, systems with GPU accelerators have two additional levels of parallelism (CPU in parallel with the GPU, and parallelism on the GPU itself) which MPI simply does not address.

On-node parallelism in HPC mostly uses OpenMP today. Classical OpenMP (OpenMP 3.1 and earlier) is well understood and available on all high-end computer systems. The later versions of OpenMP (4.0 and 4.5) include support for accelerators, such as GPUs and DSPs, managing data placement and parallel computation on the accelerator. However, there are few implementations of this and fewer mature ones.

OpenACC was developed by a subset of OpenMP members to drive the development of parallel programming directives suitable for a wide range of target systems, and specifically including accelerated systems. Many of the target features of OpenMP, such as the data directives, were first developed in OpenACC.

However, having two standards presents a problem for programmers. If they are programming for Cori using the Intel compilers, they will be using OpenMP 4 directives, probably without any target features since Knights Landing is not an accelerator. If they are programming for Titan today or Summit or Sierra tomorrow, they may well be using OpenACC directives with the PGI or other compilers, to control parallelism on the GPUs as well as the CPUs. If they are programming for their cluster at home, they may be using OpenMP with the GCC compilers, with much less parallelism to worry about. And, to make matters worse, they probably have to support all those targets at once, since they are developing locally but want production runs on whatever big system on which they can get time. Moreover, their application is being developed and extended over a period of years, and years from now the high-end systems may well be something completely different.

We will address this problem by creating a program translation tool, which we call MPACCT, that translates OpenACC programs into target-specific OpenMP programs. The translation uses four inputs:

  1. the OpenACC directives, and specifically the parallelism directives;
  2. additional parallelism discovered using classical compiler autoparallelization;
  3. characteristics of the program, including data reference patterns and program structures; and
  4. features of the target system, such as number and types of cores, availability and capability of SIMD instructions, threads per core, cache sharing patterns, and more.

Objectives

The primary objective and artifact is MPACCT, the translator itself. This tool will be based on <name your favorite compiler infrastructure here>, and will support Fortran, C and C++ <or some subset thereof> programs. In basic mode, the MPACCT driver will be given the input program and the local configuration file. The configuration file describes the target system features that control the translation process, and the target compiler. The driver will invoke the MPACCT translator to generate a target-specific OpenMP program. Then the driver will invoke the target compiler to generate an object or executable file. In this way, the MPACCT driver will be a drop-in replacement for any compiler driver (gcc, icc, pgcc, llc, xlc, and so on).

A secondary objective is to characterize and represent the parallelism profile of a range of target systems. For multicore systems, the parallelism profile will include at least the number of cores, hardware threads per core, SIMD capability, and cache configuration. For GPU-accelerated systems, it will include the number of CPU- core analogs, the depth of multithreading, the SIMD (or SIMT) width, and hardware parallelism support. We expect to identify other important system features as we develop more program optimization techniques that depend on the target systems. We plan to publish a table describing the parallelism profile for each of the target systems on which we experiment.

A third objective is to derive a language to control the MPACCT translation and optimization process. We expect the translation to depend on target system features and on program features. What we want is a way to give predicates or weights on the code optimization and generation process based on program features and target system features. This idea is still in its infancy at this point.

Significance

The most significant result will be showing that a large number of programs can be ported across widely different node architectures by just recompiling. This kind of portability is highly desirable, but there is a great deal of skepticism as to whether it is feasible. In particular, recent presentations have stated that the only way to maintain performance across different systems is to use conditional compilation (ifdef preprocessor statements) with code or directives specific to each architecture. Quoting from the NERSC 2014 Annual Report [3], “In 2014, NERSC and Cray established a joint Center of Excellence to help users port and optimize target applications that will run on Cori…” Imagine what will happen when those codes need to be run on a different architecture. Imagine instead what would happen if they could be written so porting was mostly tuning a translator and recompiling.

We expect our results to also feed into the language design, compiler and system architecture communities.

The process of porting codes across various systems will allow us to explore new language primitives that allow more flexibility when generating the output code. The mechanisms used in MPACCT can then be reproduced in other open source or commercial compilers. Finally, when porting programs between two or more system architectures, some program features will perform better on one or the other. As we explore the translator optimizations, we will be uniquely positioned to comment and give feedback about the importance or lack thereof of certain architectural features for HPC.

Present State of Knowledge

Compilers for languages like OpenMP 3.1 are mature and well developed. Compilers for a more flexible language like OpenACC are less mature. There are commercial OpenACC compilers supporting multiple GPU targets and multicore processors as well. However, outside of a few workshop presentations [4] and marketing literature, there are few details about how these compilers are implemented.

Other relevant compiler technology is mature, such as that used in classical parallelizing compilers [5]. We expect to build on that work as we develop our translator. Our contribution is not the development of new program analysis methods, but how to use the knowledge from the program and compiler analysis to map the program optimally to the target architecture.

Development Plan

Year 1:

  • Collect the infrastructure to do the program analysis: program intermediate representation, parallelization analysis; build the code generator; define the interface between the parallelism mapping phase and the code generator.
  • Study the target system architectures and collect the key architectural differences.
  • Get initial access to the target systems.
  • Collect small, medium and large benchmark programs; use the small programs to build an initial performance training set, to collect performance of variants of a program on the target systems.

Year 2:

  • Design and build a set of program transformations in the code generator; build a test engine that will test correctness of each transformation in any legal combination with any other transformation.
  • Build a test engine to test each possible program parallelism configuration on any target system; collect performance information and correlate that with architectural features; design how the parallelism mapper will drive the transformation and optimization process.
  • Formalize the architectural feature set; design an architectural description language; implement a scheme to input that language to MPACCT.

Year 3:

  • Compare MPACCT performance on various systems with native compiler performance, and with manually-tuned applications.
  • Continue to tune the parallelism mapper.
  • Look at new architectures, and demonstrate that our architectural description language can be used to tune MPACCT for a previously unseen architecture.

Experimental Procedures

Our experiments are essentially all performance measurements. We will use standard procedures for measuring performance, such as ensuring the system is otherwise unloaded, running every program three times and saving middle measurement, running with multiple host compilers and optimization levels.

Results from Prior Support

You’re pretty much on your own here.

References

  1. OpenACC-Standard.org, The OpenACC Application Programming Interface, Version 2.5, October 2015; http://www.openacc.org.
  2. OpenMP Architecture Review Board, OpenAP Application Programming Interface, Version 4.5, November 2015; http://openmp.org/wp.
  3. 2014 Annual Report, National Energy Research Scientific Computing Center.
  4. Michael Wolfe, “Implementing the PGI Accelerator Model,” in GPGPU-3, Pittsburgh, Penn., March,2010; http://dl.acm.org/citation.cfm?id=1735697.
  5. Michael Wolfe, High Performance Compilers for Parallel Computing, Addison-Wesley, 1996.
  6. Cheng Chen, Canqun Yang, Tao Tang, Qiang Wu, Pengfei Zhang, “OpenACC to Intel Offload:Automatic Translation and Optimization,” National Conference on Computer Engineering andTechnology 2013, July 20-22, 2013, Springer-Verlag, pp. 111-120.
  7. Galen Arnold, Alexander Calvert, Jeffery Overbey, Nawrin Sultana, “From OpenACC to OpenMP 4: Toward Automatic Translation,” in XCEDE16, Miami, Florida, July 17-21, 2016.

Biographical Sketches

I am an individual!

Budget

Four smart and hard-working graduate students plus one staff member for three calendar years. Travel to three conferences each year, including SC; other relevant conferences include ASPLOS, CGO, HPCA, ICPP, ICS, IPDPS, ISC, ISCA, SIGMicro, PACT, PLDI, PPoPP, and various workshops attached to these.

Equipment

This work will require workstations for the staff, and access to a variety of high-end systems. Since we are not evaluating parallelism across nodes, we don’t expect to require access to many nodes of any one system, but we do want as wide a variety of target systems as is feasible.

Summary

Have fun! I look forward to seeing the results of your research.

 

michael-wolfeAbout the Author
Michael Wolfe has been a compiler developer for over 40 years in both academia and industry, and has been working on the PGI compilers for the past 20 years, and if he were still in academia, he would be working on this proposal in earnest. The opinions stated here are those of the author, and do not represent opinions of NVIDIA. Follow Michael’s tweek (weekly tweet) @pgicompilers.

Subscribe to HPCwire's Weekly Update!

Be the most informed person in the room! Stay ahead of the tech trends with industy updates delivered to you every week!

Women Coders from Russia, Italy, and Poland Top Study

January 17, 2017

According to a study posted on HackerRank today the best women coders as judged by performance on HackerRank challenges come from Russia, Italy, and Poland. Read more…

By John Russell

Spurred by Global Ambitions, Inspur in Joint HPC Deal with DDN

January 17, 2017

Inspur, the fast-growth cloud computing and server vendor from China that has several systems on the current Top500 list, and DDN, a leader in high-end storage, have announced a joint sales and marketing agreement to produce solutions based on DDN storage platforms integrated with servers, networking, software and services from Inspur. Read more…

By Doug Black

Weekly Twitter Roundup (Jan. 12, 2017)

January 12, 2017

Here at HPCwire, we aim to keep the HPC community apprised of the most relevant and interesting news items that get tweeted throughout the week. Read more…

By Thomas Ayres

NSF Seeks Input on Cyberinfrastructure Advances Needed

January 12, 2017

In cased you missed it, the National Science Foundation posted a “Dear Colleague Letter” (DCL) late last week seeking input on needs for the next generation of cyberinfrastructure to support science and engineering. Read more…

By John Russell

HPE Extreme Performance Solutions

Remote Visualization: An Integral Technology for Upstream Oil & Gas

As the exploration and production (E&P) of natural resources evolves into an even more complex and vital task, visualization technology has become integral for the upstream oil and gas industry. Read more…

NSF Approves Bridges Phase 2 Upgrade for Broader Research Use

January 12, 2017

The recently completed phase 2 upgrade of the Bridges supercomputer at the Pittsburgh Supercomputing Center (PSC) has been approved by the National Science Foundation (NSF) making it now available for research allocations to the national scientific community, according to an announcement posted this week on the XSEDE web site. Read more…

By John Russell

Clemson Software Optimizes Big Data Transfers

January 11, 2017

Data-intensive science is not a new phenomenon as the high-energy physics and astrophysics communities can certainly attest, but today more and more scientists are facing steep data and throughput challenges fueled by soaring data volumes and the demands of global-scale collaboration. Read more…

By Tiffany Trader

For IBM/OpenPOWER: Success in 2017 = (Volume) Sales

January 11, 2017

To a large degree IBM and the OpenPOWER Foundation have done what they said they would – assembling a substantial and growing ecosystem and bringing Power-based products to market, all in about three years. Read more…

By John Russell

UberCloud Cites Progress in HPC Cloud Computing

January 10, 2017

200 HPC cloud experiments, 80 case studies, and a ton of hands-on experience gained, that’s the harvest of four years of UberCloud HPC Experiments. Read more…

By Wolfgang Gentzsch and Burak Yenier

Spurred by Global Ambitions, Inspur in Joint HPC Deal with DDN

January 17, 2017

Inspur, the fast-growth cloud computing and server vendor from China that has several systems on the current Top500 list, and DDN, a leader in high-end storage, have announced a joint sales and marketing agreement to produce solutions based on DDN storage platforms integrated with servers, networking, software and services from Inspur. Read more…

By Doug Black

For IBM/OpenPOWER: Success in 2017 = (Volume) Sales

January 11, 2017

To a large degree IBM and the OpenPOWER Foundation have done what they said they would – assembling a substantial and growing ecosystem and bringing Power-based products to market, all in about three years. Read more…

By John Russell

UberCloud Cites Progress in HPC Cloud Computing

January 10, 2017

200 HPC cloud experiments, 80 case studies, and a ton of hands-on experience gained, that’s the harvest of four years of UberCloud HPC Experiments. Read more…

By Wolfgang Gentzsch and Burak Yenier

A Conversation with Women in HPC Director Toni Collis

January 6, 2017

In this SC16 video interview, HPCwire Managing Editor Tiffany Trader sits down with Toni Collis, the director and founder of the Women in HPC (WHPC) network, to discuss the strides made since the organization’s debut in 2014. Read more…

By Tiffany Trader

BioTeam’s Berman Charts 2017 HPC Trends in Life Sciences

January 4, 2017

Twenty years ago high performance computing was nearly absent from life sciences. Today it’s used throughout life sciences and biomedical research. Genomics and the data deluge from modern lab instruments are the main drivers, but so is the longer-term desire to perform predictive simulation in support of Precision Medicine (PM). There’s even a specialized life sciences supercomputer, ‘Anton’ from D.E. Shaw Research, and the Pittsburgh Supercomputing Center is standing up its second Anton 2 and actively soliciting project proposals. There’s a lot going on. Read more…

By John Russell

Fast Rewind: 2016 Was a Wild Ride for HPC

December 23, 2016

Some years quietly sneak by – 2016 not so much. It’s safe to say there are always forces reshaping the HPC landscape but this year’s bunch seemed like a noisy lot. Among the noisemakers: TaihuLight, DGX-1/Pascal, Dell EMC & HPE-SGI et al., KNL to market, OPA-IB chest thumping, Fujitsu-ARM, new U.S. President-elect, BREXIT, JR’s Intel Exit, Exascale (whatever that means now), NCSA@30, whither NSCI, Deep Learning mania, HPC identity crisis…You get the picture. Read more…

By John Russell

AWI Uses New Cray Cluster for Earth Sciences and Bioinformatics

December 22, 2016

The Alfred Wegener Institute, Helmholtz Centre for Polar and Marine Research (AWI), headquartered in Bremerhaven, Germany, is one of the country's premier research institutes within the Helmholtz Association of German Research Centres, and is an internationally respected center of expertise for polar and marine research. In November 2015, AWI awarded Cray a contract to install a cluster supercomputer that would help the institute accelerate time to discovery. Now the effort is starting to pay off. Read more…

By Linda Barney

Addison Snell: The ‘Wild West’ of HPC Disaggregation

December 16, 2016

We caught up with Addison Snell, CEO of HPC industry watcher Intersect360, at SC16 last month, and Snell had his expected, extensive list of insights into trends driving advanced-scale technology in both the commercial and research sectors. Read more…

By Doug Black

AWS Beats Azure to K80 General Availability

September 30, 2016

Amazon Web Services has seeded its cloud with Nvidia Tesla K80 GPUs to meet the growing demand for accelerated computing across an increasingly-diverse range of workloads. The P2 instance family is a welcome addition for compute- and data-focused users who were growing frustrated with the performance limitations of Amazon's G2 instances, which are backed by three-year-old Nvidia GRID K520 graphics cards. Read more…

By Tiffany Trader

US, China Vie for Supercomputing Supremacy

November 14, 2016

The 48th edition of the TOP500 list is fresh off the presses and while there is no new number one system, as previously teased by China, there are a number of notable entrants from the US and around the world and significant trends to report on. Read more…

By Tiffany Trader

Vectors: How the Old Became New Again in Supercomputing

September 26, 2016

Vector instructions, once a powerful performance innovation of supercomputing in the 1970s and 1980s became an obsolete technology in the 1990s. But like the mythical phoenix bird, vector instructions have arisen from the ashes. Here is the history of a technology that went from new to old then back to new. Read more…

By Lynd Stringer

For IBM/OpenPOWER: Success in 2017 = (Volume) Sales

January 11, 2017

To a large degree IBM and the OpenPOWER Foundation have done what they said they would – assembling a substantial and growing ecosystem and bringing Power-based products to market, all in about three years. Read more…

By John Russell

Container App ‘Singularity’ Eases Scientific Computing

October 20, 2016

HPC container platform Singularity is just six months out from its 1.0 release but already is making inroads across the HPC research landscape. It's in use at Lawrence Berkeley National Laboratory (LBNL), where Singularity founder Gregory Kurtzer has worked in the High Performance Computing Services (HPCS) group for 16 years. Read more…

By Tiffany Trader

Dell EMC Engineers Strategy to Democratize HPC

September 29, 2016

The freshly minted Dell EMC division of Dell Technologies is on a mission to take HPC mainstream with a strategy that hinges on engineered solutions, beginning with a focus on three industry verticals: manufacturing, research and life sciences. "Unlike traditional HPC where everybody bought parts, assembled parts and ran the workloads and did iterative engineering, we want folks to focus on time to innovation and let us worry about the infrastructure," said Jim Ganthier, senior vice president, validated solutions organization at Dell EMC Converged Platforms Solution Division. Read more…

By Tiffany Trader

Lighting up Aurora: Behind the Scenes at the Creation of the DOE’s Upcoming 200 Petaflops Supercomputer

December 1, 2016

In April 2015, U.S. Department of Energy Undersecretary Franklin Orr announced that Intel would be the prime contractor for Aurora: Read more…

By Jan Rowell

Enlisting Deep Learning in the War on Cancer

December 7, 2016

Sometime in Q2 2017 the first ‘results’ of the Joint Design of Advanced Computing Solutions for Cancer (JDACS4C) will become publicly available according to Rick Stevens. He leads one of three JDACS4C pilot projects pressing deep learning (DL) into service in the War on Cancer. Read more…

By John Russell

Leading Solution Providers

D-Wave SC16 Update: What’s Bo Ewald Saying These Days

November 18, 2016

Tucked in a back section of the SC16 exhibit hall, quantum computing pioneer D-Wave has been talking up its new 2000-qubit processor announced in September. Forget for a moment the criticism sometimes aimed at D-Wave. This small Canadian company has sold several machines including, for example, ones to Lockheed and NASA, and has worked with Google on mapping machine learning problems to quantum computing. In July Los Alamos National Laboratory took possession of a 1000-quibit D-Wave 2X system that LANL ordered a year ago around the time of SC15. Read more…

By John Russell

CPU Benchmarking: Haswell Versus POWER8

June 2, 2015

With OpenPOWER activity ramping up and IBM’s prominent role in the upcoming DOE machines Summit and Sierra, it’s a good time to look at how the IBM POWER CPU stacks up against the x86 Xeon Haswell CPU from Intel. Read more…

By Tiffany Trader

Nvidia Sees Bright Future for AI Supercomputing

November 23, 2016

Graphics chipmaker Nvidia made a strong showing at SC16 in Salt Lake City last week. Read more…

By Tiffany Trader

New Genomics Pipeline Combines AWS, Local HPC, and Supercomputing

September 22, 2016

Declining DNA sequencing costs and the rush to do whole genome sequencing (WGS) of large cohort populations – think 5000 subjects now, but many more thousands soon – presents a formidable computational challenge to researchers attempting to make sense of large cohort datasets. Read more…

By John Russell

Beyond von Neumann, Neuromorphic Computing Steadily Advances

March 21, 2016

Neuromorphic computing – brain inspired computing – has long been a tantalizing goal. The human brain does with around 20 watts what supercomputers do with megawatts. And power consumption isn’t the only difference. Fundamentally, brains ‘think differently’ than the von Neumann architecture-based computers. While neuromorphic computing progress has been intriguing, it has still not proven very practical. Read more…

By John Russell

The Exascale Computing Project Awards $39.8M to 22 Projects

September 7, 2016

The Department of Energy’s Exascale Computing Project (ECP) hit an important milestone today with the announcement of its first round of funding, moving the nation closer to its goal of reaching capable exascale computing by 2023. Read more…

By Tiffany Trader

Dell Knights Landing Machine Sets New STAC Records

November 2, 2016

The Securities Technology Analysis Center, commonly known as STAC, has released a new report characterizing the performance of the Knight Landing-based Dell PowerEdge C6320p server on the STAC-A2 benchmarking suite, widely used by the financial services industry to test and evaluate computing platforms. The Dell machine has set new records for both the baseline Greeks benchmark and the large Greeks benchmark. Read more…

By Tiffany Trader

What Knights Landing Is Not

June 18, 2016

As we get ready to launch the newest member of the Intel Xeon Phi family, code named Knights Landing, it is natural that there be some questions and potentially some confusion. Read more…

By James Reinders, Intel

  • arrow
  • Click Here for More Headlines
  • arrow
Share This