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!

Scientists Conduct First Quantum Simulation of Atomic Nucleus

May 23, 2018

OAK RIDGE, Tenn., May 23, 2018—Scientists at the Department of Energy’s Oak Ridge National Laboratory are the first to successfully simulate an atomic nucleus using a quantum computer. The results, published in Ph Read more…

By Rachel Harken, ORNL

Pattern Computer – Startup Claims Breakthrough in ‘Pattern Discovery’ Technology

May 23, 2018

If it weren’t for the heavy-hitter technology team behind start-up Pattern Computer, which emerged from stealth today in a live-streamed event from San Francisco, one would be tempted to dismiss its claims of inventing Read more…

By John Russell

Intel, Micro Debut Quad-Level Cell NAND Flash

May 22, 2018

Chipmakers continue to gear designs toward AI and other demanding cloud workloads that take advantage of datacenter flash storage capacity. To that end, memory specialist Micron Technology Inc. began shipping compact sol Read more…

By George Leopold

HPE Extreme Performance Solutions

HPC and AI Convergence is Accelerating New Levels of Intelligence

Data analytics is the most valuable tool in the digital marketplace – so much so that organizations are employing high performance computing (HPC) capabilities to rapidly collect, share, and analyze endless streams of data. Read more…

IBM Accelerated Insights

Mastering the Big Data Challenge in Cognitive Healthcare

Patrick Chain, genomics researcher at Los Alamos National Laboratory, posed a question in a recent blog: What if a nurse could swipe a patient’s saliva and run a quick genetic test to determine if the patient’s sore throat was caused by a cold virus or a bacterial infection? Read more…

Japan Meteorological Agency Takes Delivery of Pair of Crays

May 21, 2018

Cray has supplied two identical Cray XC50 supercomputers to the Japan Meteorological Agency (JMA) in northwestern Tokyo. Boasting more than 18 petaflops combined peak computing capacity, the new systems will extend the a Read more…

By Tiffany Trader

Pattern Computer – Startup Claims Breakthrough in ‘Pattern Discovery’ Technology

May 23, 2018

If it weren’t for the heavy-hitter technology team behind start-up Pattern Computer, which emerged from stealth today in a live-streamed event from San Franci Read more…

By John Russell

Japan Meteorological Agency Takes Delivery of Pair of Crays

May 21, 2018

Cray has supplied two identical Cray XC50 supercomputers to the Japan Meteorological Agency (JMA) in northwestern Tokyo. Boasting more than 18 petaflops combine Read more…

By Tiffany Trader

ASC18: Final Results Revealed & Wrapped Up

May 17, 2018

It was an exciting week at ASC18 in Nanyang, China. The student teams braved extreme heat, extremely difficult applications, and extreme competition in order to cross the cluster competition finish line. The gala awards ceremony took place on Wednesday. The auditorium was packed with student teams, various dignitaries, the media, and other interested parties. So what happened? Read more…

By Dan Olds

Spring Meetings Underscore Quantum Computing’s Rise

May 17, 2018

The month of April 2018 saw four very important and interesting meetings to discuss the state of quantum computing technologies, their potential impacts, and th Read more…

By Alex R. Larzelere

Quantum Network Hub Opens in Japan

May 17, 2018

Following on the launch of its Q Commercial quantum network last December with 12 industrial and academic partners, the official Japanese hub at Keio University is now open to facilitate the exploration of quantum applications important to science and business. The news comes a week after IBM announced that North Carolina State University was the first U.S. university to join its Q Network. Read more…

By Tiffany Trader

Democratizing HPC: OSC Releases Version 1.3 of OnDemand

May 16, 2018

Making HPC resources readily available and easier to use for scientists who may have less HPC expertise is an ongoing challenge. Open OnDemand is a project by t Read more…

By John Russell

PRACE 2017 Annual Report: Exascale Aspirations; Industry Collaboration; HPC Training

May 15, 2018

The Partnership for Advanced Computing in Europe (PRACE) today released its annual report showcasing 2017 activities and providing a glimpse into thinking about Read more…

By John Russell

US Forms AI Brain Trust

May 11, 2018

Amid calls for a U.S. strategy for promoting AI development, the Trump administration is forming a senior-level panel to help coordinate government and industry research efforts. The Select Committee on Artificial Intelligence was announced Thursday (May 10) during a White House summit organized by the Office of Science and Technology Policy (OSTP). Read more…

By George Leopold

MLPerf – Will New Machine Learning Benchmark Help Propel AI Forward?

May 2, 2018

Let the AI benchmarking wars begin. Today, a diverse group from academia and industry – Google, Baidu, Intel, AMD, Harvard, and Stanford among them – releas Read more…

By John Russell

How the Cloud Is Falling Short for HPC

March 15, 2018

The last couple of years have seen cloud computing gradually build some legitimacy within the HPC world, but still the HPC industry lies far behind enterprise I Read more…

By Chris Downing

Russian Nuclear Engineers Caught Cryptomining on Lab Supercomputer

February 12, 2018

Nuclear scientists working at the All-Russian Research Institute of Experimental Physics (RFNC-VNIIEF) have been arrested for using lab supercomputing resources to mine crypto-currency, according to a report in Russia’s Interfax News Agency. 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

Deep Learning at 15 PFlops Enables Training for Extreme Weather Identification at Scale

March 19, 2018

Petaflop per second deep learning training performance on the NERSC (National Energy Research Scientific Computing Center) Cori supercomputer has given climate Read more…

By Rob Farber

AI Cloud Competition Heats Up: Google’s TPUs, Amazon Building AI Chip

February 12, 2018

Competition in the white hot AI (and public cloud) market pits Google against Amazon this week, with Google offering AI hardware on its cloud platform intended Read more…

By Doug Black

US Plans $1.8 Billion Spend on DOE Exascale Supercomputing

April 11, 2018

On Monday, the United States Department of Energy announced its intention to procure up to three exascale supercomputers at a cost of up to $1.8 billion with th Read more…

By Tiffany Trader

Lenovo Unveils Warm Water Cooled ThinkSystem SD650 in Rampup to LRZ Install

February 22, 2018

This week Lenovo took the wraps off the ThinkSystem SD650 high-density server with third-generation direct water cooling technology developed in tandem with par Read more…

By Tiffany Trader

Leading Solution Providers

HPC and AI – Two Communities Same Future

January 25, 2018

According to Al Gara (Intel Fellow, Data Center Group), high performance computing and artificial intelligence will increasingly intertwine as we transition to Read more…

By Rob Farber

Google Chases Quantum Supremacy with 72-Qubit Processor

March 7, 2018

Google pulled ahead of the pack this week in the race toward "quantum supremacy," with the introduction of a new 72-qubit quantum processor called Bristlecone. Read more…

By Tiffany Trader

HPE Wins $57 Million DoD Supercomputing Contract

February 20, 2018

Hewlett Packard Enterprise (HPE) today revealed details of its massive $57 million HPC contract with the U.S. Department of Defense (DoD). The deal calls for HP Read more…

By Tiffany Trader

CFO Steps down in Executive Shuffle at Supermicro

January 31, 2018

Supermicro yesterday announced senior management shuffling including prominent departures, the completion of an audit linked to its delayed Nasdaq filings, and Read more…

By John Russell

Deep Learning Portends ‘Sea Change’ for Oil and Gas Sector

February 1, 2018

The billowing compute and data demands that spurred the oil and gas industry to be the largest commercial users of high-performance computing are now propelling Read more…

By Tiffany Trader

Nvidia Ups Hardware Game with 16-GPU DGX-2 Server and 18-Port NVSwitch

March 27, 2018

Nvidia unveiled a raft of new products from its annual technology conference in San Jose today, and despite not offering up a new chip architecture, there were still a few surprises in store for HPC hardware aficionados. Read more…

By Tiffany Trader

Hennessy & Patterson: A New Golden Age for Computer Architecture

April 17, 2018

On Monday June 4, 2018, 2017 A.M. Turing Award Winners John L. Hennessy and David A. Patterson will deliver the Turing Lecture at the 45th International Sympo Read more…

By Staff

Part One: Deep Dive into 2018 Trends in Life Sciences HPC

March 1, 2018

Life sciences is an interesting lens through which to see HPC. It is perhaps not an obvious choice, given life sciences’ relative newness as a heavy user of H Read more…

By John Russell

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