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.


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.


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.


  1., The OpenACC Application Programming Interface, Version 2.5, October 2015;
  2. OpenMP Architecture Review Board, OpenAP Application Programming Interface, Version 4.5, November 2015;
  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;
  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!


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.


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.


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!

Musk’s Latest Startup Eyes Brain-Computer Links

April 21, 2017

Elon Musk, the auto and space entrepreneur and severe critic of artificial intelligence, is forming a new venture that reportedly will seek to develop an interface between the human brain and computers. Read more…

By George Leopold

MIT Mathematician Spins Up 220,000-Core Google Compute Cluster

April 21, 2017

On Thursday, Google announced that MIT math professor and computational number theorist Andrew V. Sutherland had set a record for the largest Google Compute Engine (GCE) job. Sutherland ran the massive mathematics workload on 220,000 GCE cores using preemptible virtual machine instances. Read more…

By Tiffany Trader

Nvidia P100 Shows 1.3-2.3x Speedup Over K80 GPU on Financial Apps

April 20, 2017

When it comes to the true performance of the latest silicon, every end user knows that the best processor is the one that works best for their application. Read more…

By Tiffany Trader

Quantum Adds Global Smarts to StorNext File System

April 20, 2017

Companies that use Quantum’s StorNext platform to store massive amounts of data this week got a glimpse of new storage capabilities that should make it easier to access their data horde from anywhere in the world. Read more…

By Alex Woodie

HPE Extreme Performance Solutions

HPC-Driven Weather Simulations Improving Forecasting Capabilities

In September of 1938, a massive hurricane traversed the Atlantic Ocean and made landfall in New England. Due to inadequate and incorrect forecasting, the storm struck farther north and with greater intensity than had been predicted, leaving residents and authorities with virtually no warning or time to properly prepare. Read more…

Scaling an HPC Career in Nepal Can Be a Steep Climb

April 20, 2017

Umesh Upadhyaya works as an IT Associate at the International Centre for Integrated Mountain Development (ICIMOD) in Nepal, which supports the country’s one and only HPC facility. He is directly involved in an initiative that focuses on climate change and atmosphere modeling Read more…

By Nages Sieslack

Hyperion (IDC) Paints a Bullish Picture of HPC Future

April 20, 2017

Hyperion Research – formerly IDC’s HPC group – yesterday painted a fascinating and complicated portrait of the HPC community’s health and prospects at the HPC User Forum held in Albuquerque, NM. HPC sales are up and growing ($22 billion, all HPC segments, 2016). Read more…

By John Russell

Intel Open Sources All Lustre Work, Brent Gorda Exits

April 19, 2017

In a letter to the Lustre community posted on the Intel website, Vice President of Intel's Data Center Group Trish Damkroger writes that effective immediately the company will be contributing all Lustre development to the open source community. Damkroger also announced that Brent Gorda, General Manager, High Performance Data Division at Intel is leaving the company. Read more…

By Tiffany Trader

Facebook Open Sources Caffe2; Nvidia, Intel Rush to Optimize

April 18, 2017

From its F8 developer conference in San Jose, Calif., today, Facebook announced Caffe2, a new open-source, cross-platform framework for deep learning. Caffe2 is the successor to Caffe, the deep learning framework developed by Berkeley AI Research and community contributors. Read more…

By Tiffany Trader

Hyperion (IDC) Paints a Bullish Picture of HPC Future

April 20, 2017

Hyperion Research – formerly IDC’s HPC group – yesterday painted a fascinating and complicated portrait of the HPC community’s health and prospects at the HPC User Forum held in Albuquerque, NM. HPC sales are up and growing ($22 billion, all HPC segments, 2016). Read more…

By John Russell

Knights Landing Processor with Omni-Path Makes Cloud Debut

April 18, 2017

HPC cloud specialist Rescale is partnering with Intel and HPC resource provider R Systems to offer first-ever cloud access to Xeon Phi "Knights Landing" processors. The infrastructure is based on the 68-core Intel Knights Landing processor with integrated Omni-Path fabric (the 7250F Xeon Phi). Read more…

By Tiffany Trader

CERN openlab Explores New CPU/FPGA Processing Solutions

April 14, 2017

Through a CERN openlab project known as the ‘High-Throughput Computing Collaboration,’ researchers are investigating the use of various Intel technologies in data filtering and data acquisition systems. Read more…

By Linda Barney

DOE Supercomputer Achieves Record 45-Qubit Quantum Simulation

April 13, 2017

In order to simulate larger and larger quantum systems and usher in an age of “quantum supremacy,” researchers are stretching the limits of today’s most advanced supercomputers. Read more…

By Tiffany Trader

Penguin Takes a Run at the Big Cloud Providers

April 12, 2017

HPC specialist Penguin Computing recently re-ran benchmarks from a study of its larger brethren and says the results show its ‘public cloud’ – Penguin on Demand (POD) – is among the leaders in cost and performance. Read more…

By John Russell

Nvidia Responds to Google TPU Benchmarking

April 10, 2017

Nvidia highlights strengths of its newest GPU silicon in response to Google's report on the performance and energy advantages of its custom tensor processor. Read more…

By Tiffany Trader

HPC and the Colocation Datacenter – a Bridge Too Far?

April 7, 2017

A more standardised HPC platform approach is making the running of HPC projects within increasing financial reach. Read more…

By Clive Longbottom, Quocirca

Google Pulls Back the Covers on Its First Machine Learning Chip

April 6, 2017

This week Google released a report detailing the design and performance characteristics of the Tensor Processing Unit (TPU), its custom ASIC for the inference phase of neural networks (NN). Read more…

By Tiffany Trader

Google Pulls Back the Covers on Its First Machine Learning Chip

April 6, 2017

This week Google released a report detailing the design and performance characteristics of the Tensor Processing Unit (TPU), its custom ASIC for the inference phase of neural networks (NN). Read more…

By Tiffany Trader

Quantum Bits: D-Wave and VW; Google Quantum Lab; IBM Expands Access

March 21, 2017

For a technology that’s usually characterized as far off and in a distant galaxy, quantum computing has been steadily picking up steam. Read more…

By John Russell

Trump Budget Targets NIH, DOE, and EPA; No Mention of NSF

March 16, 2017

President Trump’s proposed U.S. fiscal 2018 budget issued today sharply cuts science spending while bolstering military spending as he promised during the campaign. Read more…

By John Russell

HPC Compiler Company PathScale Seeks Life Raft

March 23, 2017

HPCwire has learned that HPC compiler company PathScale has fallen on difficult times and is asking the community for help or actively seeking a buyer for its assets. Read more…

By Tiffany Trader

Nvidia Responds to Google TPU Benchmarking

April 10, 2017

Nvidia highlights strengths of its newest GPU silicon in response to Google's report on the performance and energy advantages of its custom tensor processor. 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

CPU-based Visualization Positions for Exascale Supercomputing

March 16, 2017

In this contributed perspective piece, Intel’s Jim Jeffers makes the case that CPU-based visualization is now widely adopted and as such is no longer a contrarian view, but is rather an exascale requirement. Read more…

By Jim Jeffers, Principal Engineer and Engineering Leader, Intel

TSUBAME3.0 Points to Future HPE Pascal-NVLink-OPA Server

February 17, 2017

Since our initial coverage of the TSUBAME3.0 supercomputer yesterday, more details have come to light on this innovative project. Of particular interest is a new board design for NVLink-equipped Pascal P100 GPUs that will create another entrant to the space currently occupied by Nvidia's DGX-1 system, IBM's "Minsky" platform and the Supermicro SuperServer (1028GQ-TXR). Read more…

By Tiffany Trader

Leading Solution Providers

Tokyo Tech’s TSUBAME3.0 Will Be First HPE-SGI Super

February 16, 2017

In a press event Friday afternoon local time in Japan, Tokyo Institute of Technology (Tokyo Tech) announced its plans for the TSUBAME3.0 supercomputer, which will be Japan’s “fastest AI supercomputer,” Read more…

By Tiffany Trader

IBM Wants to be “Red Hat” of Deep Learning

January 26, 2017

IBM today announced the addition of TensorFlow and Chainer deep learning frameworks to its PowerAI suite of deep learning tools, which already includes popular offerings such as Caffe, Theano, and Torch. Read more…

By John Russell

Is Liquid Cooling Ready to Go Mainstream?

February 13, 2017

Lost in the frenzy of SC16 was a substantial rise in the number of vendors showing server oriented liquid cooling technologies. Three decades ago liquid cooling was pretty much the exclusive realm of the Cray-2 and IBM mainframe class products. That’s changing. We are now seeing an emergence of x86 class server products with exotic plumbing technology ranging from Direct-to-Chip to servers and storage completely immersed in a dielectric fluid. Read more…

By Steve Campbell

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

HPC Startup Advances Auto-Parallelization’s Promise

January 23, 2017

The shift from single core to multicore hardware has made finding parallelism in codes more important than ever, but that hasn’t made the task of parallel programming any easier. Read more…

By Tiffany Trader

HPC Technique Propels Deep Learning at Scale

February 21, 2017

Researchers from Baidu’s Silicon Valley AI Lab (SVAIL) have adapted a well-known HPC communication technique to boost the speed and scale of their neural network training and now they are sharing their implementation with the larger deep learning community. Read more…

By Tiffany Trader

US Supercomputing Leaders Tackle the China Question

March 15, 2017

Joint DOE-NSA report responds to the increased global pressures impacting the competitiveness of U.S. supercomputing. Read more…

By Tiffany Trader

IDG to Be Bought by Chinese Investors; IDC to Spin Out HPC Group

January 19, 2017

US-based publishing and investment firm International Data Group, Inc. (IDG) will be acquired by a pair of Chinese investors, China Oceanwide Holdings Group Co., Ltd. Read more…

By Tiffany Trader

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